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ABSTRACT 

Naval  Aviation  conf igutation  status  accounting  and  its 
interface  with  the  present  and  future  prescribed  and  locally 
developed  information  systems  is  reviewed.   It  was  determined 
that  the  lack  of  coordination,  integration  and  standardization 
resulting  from  the  proliferation  of  locally  developed  systems 
decreases  logistic  support  and  maintenance  management  effec- 
tiveness.  It  is  recommended  that  the  prescribed  Naval  Aviation 
configuration  status  accounting  system  and  the  proliferation 
of  local  systems  be  consolidated  into  a  single  integrated 
system.   NALCOMIS,  a  program  currently  under  development,  has 
the  potential  to  meet  all  user  requirements  with  minor  expan- 
sion to  its  current  design. 
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I.   INTRODUCTION 

A.   BACKGROUND 

Between  1950  and  1979  the  n\imber  of  aircraft  purchased 
by  the  Department  of  Defense  (DOD)  decreased  from  3,000  per 
year  to  approximately  300  per  year  [Ref.  1].   However,  the 
complexity  and  unit  cost  of  these  aircraft  increased  greatly. 
As  a  result  of  a  smaller,  more  expensive,  very  highly  sophis- 
ticated aircraft  inventory  and  major  ongoing  technical  advances, 
aircraft  life  cycles  are  extended  and  capabilities  upgraded 
through  changes  and  modifications. 

Changes  to  Naval  aircraft  are  promulgated  by  the  Naval 
Air  Systems  Command  (NAVAIR)  for  specific  aircraft  type/model/ 
series.   The  actual  incorporation  of  the  changes  occurs  at 
the  organizational,  intermediate  and  depot  levels  of  maintenance 
The  incorporation  process  is  an  ongoing  one,  and  the  applica- 
bility of  changes  varies  with  aircraft  model,  series  and  bureau 
number.   Modifications  can  affect  the  logistic  support  required 
for  an  aircraft  to  varying  degrees.   While  some  changes  bring 
about  only  minor  deviations  to  the  maintenance  and  supply  re- 
quirements, others  can  cause  major  revisions.   Maintenance 
tasks,  support  equipment  requirements,  testing  procedures, 
weight  and  balance  and  spare  parts  can  all  be  affected  by  a 
single  change.   Although  identical  configuration  of  all  similar 
type/model/series  aircraft  is  a  goal,  differing  capabilities 
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are  often  desired  to  meet  operational  commitments  and/or  are 
necessary  to  remain  within  financial  constraints.   Consequent- 
ly a  functional  wing  is  composed  of  aircraft  with  varying  con- 
figurations which  subsequently  have  varying  support  requirements 

If  the  changes  incorporated  in  an  aircraft  are  properly 
documented  and  the  aircraft's  configuration  is  known,  the  lo- 
gistic support  of  the  aircraft  can  be  planned  and  carried  out. 
A  major  problem  arises  when  the  configuration  of  an  aircraft 
is  either  unknown  or  incorrectly  documented.   In  the  former 
case,  manhours  must  be  expended  to  physically  verify  the  changes 
that  have  been  incorporated  so  that  a  support  plan  can  be  drawn. 
up.   In  the  latter  case,  a  plan  will  be  pursued  but  may  be 
ineffective,  as  the  correct  spare  parts  will  not  be  stocked, 
correct  and  sufficient  support  equipment  will  not  be  available 
and  technicians  will  not  possess  the  proper  training  to  repair 
and  service  the  aircraft. 

This  problem  is  further  compounded  in  the  Navy  as  a  result 
of  the  deployment  requirements  of  aviation  units.   Maintenance 
and  supply  facilities  aboard  an  aircraft  carrier  are  limited, 
necessitating  careful  planning  and  coordination  of  all  support 
requirements.   Under  these  circumstances  incorrect  and  incom- 
plete configuration  documentation  can  thwart  logistic  support 
efforts  to  the  point  where  aircraft  are  rendered  incapable 
of  safe  flight  or  mission  performance.   Effective  maintenance 
management  is  highly  dependent  on  accurate  and  timely  config- 
uration status  accounting.   Consequently,  configuration  status 
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accounting  systems  are,  out  of  necessity,  an  integral  and  active 
part  of  maintenance  management  systems  during  the  use  period. 

B.   STATEMENT  OF  THE  PROBLEM 

The  Technical  Directive  Status  Accounting  System  is  the 
Navy  system  prescribed  for  tracking  aircraft  configuration. 
The  personal  experience  of  the  authors  at  the  squadron,  func- 
tional wing  and  carrier  air  wing  levels  is  that  this  system 
is  unreliable  and  ineffective  in  providing  valid  and  timely 
information  on  which  to  base  logistic  support  decisions.   Con- 
sequently, each  functional  wing  or  type  commander  currently 
employs  locally  initiated  systems,  ranging  from  luck  to  com- 
puter-aided management  information  systems,  for  monitoring 
and  controlling  aircraft  configuration.   The  inability  to  in- 
tegrate these  various  systems  results  in  degraded  logistic 
support  and  loss  of  continuity  for  deployed  airwings  which 
are  composed  of  squadrons  from  several  functional  wings.   In 
addition  to  aircraft  configuration  information  often  being 
incomplete  and  incorrect,  the  form,  presentation  and  accessi- 
bility are  frequently  inconsistent  across  the  airwing.   This 
greatly  decreases  the  ability  of  logistics  managers  to  provide 
proper  and  effective  support  for  a  deployed  airwing.   It  is 
the  authors'  belief  that  the  Navy  requires  a  common,  compre- 
hensive system  for  monitoring  and  controlling  aircraft  config- 
uration status  and  accountability  that  can  be  used  for  all 
type /model/series  of  aircraft. 


12 


C.  THESIS  OBJECTIVES 

The  objectives  of  this  thesis  are  as  follows: 

1.  Review  the  concept  of  configuration  management  and 
its  application  in  Naval  aviation. 

2.  Review  and  evaluate  the  Navy  Technical  Directive  Status 
Accounting  System  with  regard  to  its  effectiveness  and  defi- 
ciencies . 

3.  Review  four  major  local  systems  which  have  been  devel- 
oped to  mitigate  the  deficiencies  of  the  Technical  Directive 
Status  Accounting  System. 

4.  Provide  recommendations  for  future  direction  of  Naval 
aviation  configuration  status  accounting  programs. 

D.  THESIS  SCOPE 

Configuration  management  is  a  broad  discipline  that  is 
divided  into  several  different  facets.   Figure  1.1  shows  the 
major  facets--accounting,  identification,  control.   Properly 
done,  configuration  management  would  be  carried  out  through- 
out a  system's  life  cycle  from  its  conception  through  its  de- 
sign, production  and  use,  until  it  is  retired.   The  implementation 
and  interaction  of  the  above  facets  vary  during  the  life  cycle, 
but  all  are  present  in  one  form  or  another. 

The  scope  of  this  thesis  is  limited  in  three  respects. 
First,  the  concentration  is  on  the  accounting  segment  of  con- 
figuration management  and  more  specifically  the  area  of  config- 
uration status  accounting.   Second,  only  that  segment  of  the 
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system  life  cycle  in  which  the  system  is  operated  and  main- 
tained by  the  user  is  considered.   The  formulation,  design, 
test  and  production  portions  are  only  briefly  mentioned  with 
regard  to  configuration  status  accounting.   Third,  the  systems 
or  equipment  addressed  are  limited  to  the  hardware  under  the 
cognizance  of  the  Naval  Air  Systems  Command. 

E.   METHOD  OF  RESEARCH 

Research  for  this  thesis  was  conducted  through  a  review 
of  configuration  management  literature,  contact  with  numerous 
Navy  squadrons,  functional  wings,  type  commanders  and  higher 
level  staffs,  and  a  visit  to  Commander  Naval  Air  Force,  U.S. 
Pacific  Fleet.   The  literature  review  included  published  ar- 
ticles written  by  both  military  and  private  industry  managers, 
technical  papers  delivered  at  symposia  and  conferences.  Naval 
Audit  Service  and  Comptroller  General  reports,  and  Department 
of  Defense  and  Navy  correspondence,  directives,  instructions 
and  technical  manuals.   The  various  squadron,  functional  wing 
and  type  commander  contacts  provided  information  on  how  Naval 
aviation  units  are  currently  performing  configuration  status 
accounting.   Managers  at  the  Naval  Air  Systems  Command  and 
Naval  Material  Command  provided  insight  to  future  changes  to 
the  current  Navy  configuration  status  accounting  policy.   In 
addition,  the  personal  experience  of  both  authors  contributed 
in  a  large  degree  to  the  information  presented. 
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F.   THESIS  STRUCTURE 

1 .  Chapter  One 

This  is  a  general  introductory  chapter  which  briefly 
presents  the  problem  being  considered  and  the  thesis  objectives. 

2.  Chapter  Two 

This  chapter  presents  a  general  overview  of  configura- 
tion management  including  definitions  and  techniques.   It  also 
covers  a  brief  description  of  the  system  life  cycle  and  its 
relationship  to  configuration  management. 

3 .  Chapter  Three 

In  this  chapter.  Department  of  Defense  Directive  5010.19 
concerning  configuration  management  is  reviewed  as  well  as 
Naval  Air  Systems  Command  and  Naval  Material  Command  instruc- 
tions.  When  reviewing  Navy  instructions,  the  subject  is  nar- 
rowed from  configuration  management  as  a  whole  to  configuration 
status  accounting  specifically. 

4 .  Chapter  Four 

A  brief  discussion  of  the  importance  of  configuration 
status  accounting  and  its  interface  with  aircraft  logistic 
support  within  the  Naval  Air  Systems  Command  is  presented. 

5 .  Chapter  Five 

In  Chapter  Five  the  Technical  Directive  Status  Accounting 
System,  the  prescribed  system  for  accomplishing  configuration 
status  accounting  within  the  Naval  Air  System  Command,  is 
reviewed. 
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6 .  Chapter  Six 

Some  of  the  major  deficiencies  of  the  Technical  Direc- 
tive Status  Accounting  System  reviewed  in  Chapter  Five  are 
discussed  in  this  chapter.   Four  local  systems  independently 
developed  at  various  levels  throughout  the  Navy  to  alleviate 
those  deficiencies  are  presented. 

7 .  Chapter  Seven 

In  this  chapter  an  outline  of  the  Naval  Aviation  Logis- 
tics Command  Management  Information  System  as  it  relates  to 
configuration  status  accounting  is  presented.   This  system, 
which  is  in  the  prototype  phase,  has  been  designed  to  improve 
the  management  of  aircraft  maintenance  including  configuration 
management. 

8  .   Chapter  Eight 

This  concluding  chapter  presents  the  authors'  views 
of  where  the  Naval  Air  Systems  Command  stands  today  with  re- 
gard to  configuration  status  accounting.   It  also  includes 
recommendations  for  action  to  be  taken  now  and  in  the  future. 
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II.   CONFIGURATION  MANAGEMENT  OVERVIEW 

A.  INTRODUCTION 

Configuration  management  is  a  relatively  new  discipline 
in  military  management  when  considered  in  a  formal  sense,  al- 
though it  has  long  been  practiced  informally  by  commercial 
companies  [Ref.  2].   The  advent  of  the  missile/space  race  in 
the  1950 's  brought  with  it  products  that  were  characterized 
by  a  high  incidence  of  change.   These  changes  were  accepted 
results  of  "the  technical  complexity,  high  reliability,  ex- 
tensive software,  complex  support,  high  subcontract  rate  and 
the  essentially  developmental  nature  of  the  industry"  [Ref.  2]. 
The  continued  production,  operation,  and  support  of  such  pro- 
ducts require  documentation  and  strict  control  over  their  con- 
figuration.  Thus  it  was  necessary  to  develop  a  formal  system 
to  replace  the  informal  methods  then  in  use  whereby  the  pro- 
duct's functions  and  equipment  could  be  identified,  controlled 
and  documented  throughout  its  life. 

B.  DEFINITION 

The  literature  contains  several  definitions,  both  formal 

and  informal,  of  configuration  management.   Some  of  these  follow; 

Configuration  Management  is  a  management  science  that  pro- 
vides a  disciplined  environment  and  administrative  frame- 
work for  the  precise  definition  and  control  of  product 
configuration  throughout  its  life  cycle  [Ref.  2] . 

It  [configuration  management]  defines  the  product,  its 
components,  and  their  interfaces.   It  restricts  idle  change, 
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and  it  requires  precise  records  of  the  changes  that  are 
authorized  [Ref .  3] . 

Configuration  management  is  the  art  of  organizing  and 
controlling  planning,  design,  development,  and  hardware 
operations  by  means  of  uniform  configuration  control, 
identification  and  accounting  of  a  product  [Ref.  4]. 

There  are  some  important  points  in  these  definitions  that 
deserve  further  comment.   First  of  all,  there  is  an  emphasis 
on  discipline,  precision  and  organization.   Fragmented,  un- 
supported methods  for  managing  configuration  have  been  proven 
ineffective.   Second,  a  degree  of  uniformity  or  a  framework 
is  stipulated.   This  is  necessary  to  assure  some  sort  of  con- 
sistency of  information  and  policy  across  industries.   Third, 
the  term  "configuration"  applies  to  the  physical  and  functional 
characteristics  of  a  product  as  well  as  to  the  information 
required  to  build  and  support  it  [Ref.  4].   This  encompasses 
both  hardware  and  software,  design,  build,  test,  operation  and 
maintenance.   Fourth,  configuration  management  applies  through- 
out a  product's  life. 

C.   SYSTEM  LIFE  CYCLE 

All  products  or  systems  result  from  a  perceived  need,  new 
technology  or  a  replacement  of  products  or  systems  that  have 
become  obsolete  [Ref.  5].   They  then  progress  through  several 
phases  which  compose  their  life  cycle  as  shown  in  Figure  2.1. 
Out  of  these  phases  emerges  the  product  or  system  which  will 
satisfy  the  need.   As  it  progresses  through  development,  its 
configuration  is  defined  more  precisely.   In  addition,  changes 
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can  occur.   This  process  is  essentially  a  progressive  defini- 
tion of  a  system's  configuration  and  it  is  a  key  concept  in 
configuration  management  [Ref.  4]. 

The  first  step  in  this  progressive  definition  is  to  define 
the  system  in  operational  terms  and  determine  the  feasibility 
of  pursuing  its  development.   This  occurs  during  the  Concept 
Formulation  Phase  of  its  life  cycle.   No  specific  hardware 
is  identified  at  this  point,  but  rather  the  basic  mission  the 
system  must  perform  is  identified.   The  output  of  this  phase 
are  the  operational  requirements  or  characteristics  for  the 
system.   During  the  next  phase,  which  is  the  System  Definition 
Phase,  physical  requirements  are  stipulated  for  the  system. 
These  are  requirements  and  constraints  such  as  size,  weight, 
maintainability,  etc.  and  are  the  inputs  for  the  next  phase, 
the  Design  Phase.   It  is  during  this  phase  that  specific  hard- 
ware is  fitted  to  the  requirements,  and  the  result  or  output 
is  a  model  of  the  system.   The  model  is  subjected  to  test  and 
evaluation  where  changes  may  occur.   The  final  output  will 
result  in  the  actual  configuration  that  serves  as  the  input 
for  the  Production  and  Installation  Phases. 

As  can  be  seen  in  Figure  2.1,  the  following  two  phases, 
the  Operations  and  Support  Phase  and  the  Modification  and  Re- 
tirement Phase,  comprise  the  Use  Period  for  the  system.   The 
system  is  transferred  from  the  manufacturer  (or  producer)  to 
the  user  where  it  performs  its  intended  mission.   Once  the 
system  enters  the  Use  Period,  configuration  management  is 
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essential  and  can  become  more  complex.   Changes  may  be  required 
for  the  system  to  perform  its  originally  intended  function. 
In  addition,  changing  needs  or  technology  may  modify  its  re- 
quired function,  making  further  modifications  necessary  at 
any  point  in  its  Use  Period.   Prior  to  the  Use  Period,  any 
changes  to  the  system's  configuration  are  performed  and  docu- 
mented by  the  manufacturer  with  the  participation  and  concur- 
rence of  the  user.   However,  after  entering  the  Use  Period, 
the  user  assumes  primary  responsibility  for  change  incorpora- 
tion, documentation  and  progressive  definition  of  the  configu- 
ration throughout  this  period  to  retirement. 

In  summary,  the  progressive  definition  concept  of  config- 
uration management  describes  the  process  whereby,  "...the  con- 
figuration of  a  product  is  derived  during  development,  determined 
during  design,  established  during  production,  and  maintained 
during  operational  support."  [Ref.  4] 

D.   BASELINE  MANAGEMENT 

A  system's  configuration  is  monitored  and  controlled  during 
progressive  definition  by  means  of  a  concept  called  "baseline 
management".   A  baseline  is  established  by  compiling  technical 
documentation  of  the  system  at  various  points  in  its  life  cycle. 
This  documentation  describes  the  system  in  terms  of  its  physi- 
cal and  functional  characteristics  at  that  point  and  must  be 
agreed  upon  by  both  the  customer  and  the  contractor.   The  estab- 
lished baselines  are  major  control  points  necessary  for  further 
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advancement  through  the  system's  life  cycle.   Deviations  from 
an  established  baseline  must  be  approved  by  both  the  customer 
and  contractor  and  must  be  documented  in  a  manner  that  facili- 
tates ease  of  configuration  identification  at  any  point  in 
t  ime  .  [  Re  f .  6  ] 

Baselines  are  established  at  a  minimum  of  three  and  up 
to  six  points  during  the  system  life  cycle.   Samaras  and 
Czerwinski  identify  three  contractual  and  three  recommended 
internal  baselines,  as  depicted  in  Figure  2.2  [Ref.  4]. (Their 
Acquisition  Phase  is  equivalent  to  the  Acquisition  Period  in 
Figure  2.1).   The  contractual  baselines  are  the  Functional, 
Allocated  and  Product  Baselines  which  are  established  at  the 
end  of  the  Conceptual,  Definition  and  Design  phases  respec- 
tively.  They  further  recommend  that  Design,  Development  and 
Production  baselines  be  established  at  the  indicated  points 
within  the  Design  Phase. 

In  the  Functional  Baseline,  specifications  that  define 
the  program  requirements  are  established.   It  is  in  this  base- 
line that  the  identified  need  which  originated  the  requirement 
for  the  system  is  defined  in  performance  and  operational  terms 

During  the  next  phase,  these  objectives  are  allocated  to 
their  respective  elements  known  as  configuration  items  (CI) 
within  the  system.   Further,  the  design  requirements  for  the 
elements  are  identified.   These  elements  and  their  performance 
specifications  establish  the  Allocated  Baseline. 
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Various  internal  baselines  may  be  established  during  the 
Design  Phase,  as  shown  in  Figure  2.2.   In  terms  of  progres- 
sive definition,  this  is  where  the  configuration  of  the  system 
that  will  be  delivered  to  the  customer  is  increasingly  defined 
as  the  design  proceeds.   The  culmination  of  this  phase  pro- 
duces the  Product  Baseline. 

Strict  control  of  configuration  deviations  from  the  Product 
Baseline  is  maintained  with  the  customer  approving  all  changes. 
This  strict  control  assures  that  the  customer  receives  a  sys- 
tem that  comforms  totally  with  both  the  specifications  in  the 
Product  Baseline  and  all  approved  and  documented  changes  thereto 

When  the  system  enters  the  Use  Period,  incorporation  and 
documentation  of  changes  to  the  Product  Baseline  become  the 
responsibility  of  the  customer.   This  thesis  focuses  on  the 
documentation  and  status  accounting  of  changes  incorporated 
from  the  Use  Period  on.   If  efficient  configuration  management 
is  to  be  successfully  carried  out,  the  Product  Baseline  with 
its  documented  changes  must  be  maintained  in  a  current  status 
at  all  times.   However,  as  the  system  leaves  the  controlled 
environment  of  the  manufacturer  and  transitions  to  the  oper- 
ational environment,  its  configuration  management  can  become 
more  difficult  and  involved. 

E.   CONFIGURATION  MANAGEMENT  TECHNIQUES 

Monitoring  and  directing  baseline  configuration  requires 
a  progressively  stricter  control  process  as  each  baseline  is 
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established  [Ref.  2].   Therefore,  configuration  management 
is  comprised  of  various  techniques  for  its  systematic  appli- 
cation throughout  the  system  life  cycle  [Ref.  4]. 

1 .  Configuration  Identification 

Configuration  identification,  as  the  term  implies, 
identifies  the  physical  and  functional  characteristics  of  a 
system.   It  is  comprised  of  the  complete  system  documentation 
such  as  specifications,  engineering  drawings,  data  lists  and 
other  information  required  to  completely  define  the  system's 
configuration  and  any  approved  changes  to  it.   The  configura- 
tion identification  is  detailed  to  the  degree  that  serial  num- 
bers of  assemblies,  subassemblies  and  parts  are  identified 
on  the  documentation.   The  purpose  is  to  assure  that  the  hard- 
ware and  accompanying  documentation  coincide  throughout  the 
life  cycle. 

2 .  Configuration  Control 

A  process  which  starts  at  the  beginning  of  and  continues 
throughout  the  life  cycle,  configuration  control  provides  the 
management  framework  for  proposing,  evaluating,  approving  or 
disapproving  and  documenting  changes  to  the  system.   Config- 
uration control  is  limited  in  the  early  life  cycle  phases  to 
the  functional  requirements  (Functional  Baseline) ,  and  the 
proposed  configuration  and  specifications  (Allocated  Baseline) . 
In  the  later  phases  it  applies  to  the  actual  hardware  and  soft- 
ware which  comprise  the  system  (Product  Baseline) . 
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3 .  Configuration  Verification 

Incorporation  of  approved  changes  may  or  may  not  pro- 
ceed as  planned  and/or  documented.   It  is  necessary,   there- 
fore, to  compare  or  verify  the  approved  documented  baseline 
and  incorporated  changes  with  the  actual  hardware  and  software 
contained  in  the  system.   Inherent  in  this  configuration  veri- 
fication process  is  the  identification  and  subsequent  correc- 
tion of  configuration  discrepancies  by  either  updating  the 
system  to  conform  with  its  approved  configuration  or  approving 
its  present  configuration  as  is.   In  the  latter  case,  the  dis- 
crepancies and  buyer's  approval  of  those  discrepancies  are 
noted. 

4 .  Configuration  Accounting  and  Reporting 
Configuration  accounting  and  reporting  provides  the 

administrative  framework  for  documenting  a  system's  location, 
its  component  makeup  by  serial  number  and  its  current  config- 
uration.  It  establishes  the  system  for  recording  and  reporting 
the  incorporation  of  approved  changes.   The  process  continues 
throughout  the  life  of  the  system  and  "establishes  records 
which  enable  proper  logistic  support  to  be  established"  [Ref.  4] 

5 .  Configuration  Audit  and  Review 

Configuration  audits  are  designed  and  conducted  to  deter- 
mine if  the  functional  and  physical  characteristics  in  the 
system's  configuration  identification  match  the  system's  actual 
physical  and  functional  characteristics.   These  are  formal 
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audits  which  are  selectively  performed  on  items  and  contri- 
bute to  the  establishment  of  the  Product  Baseline  (especially 
on  the  first  production  article  called  First  Article  Config- 
uration Identification  or  First  Article  Configuration  Review) 
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III.   CONFIGURATION  MANAGEMENT  STATUS  ACCOUNTING 
WITHIN  THE  DEPARTMENT  OF  DEFENSE 

A.   DOD  CONFIGURATION  MANAGEMENT  POLICY 

According  to  the  DOD,  the  purpose  of  configuration  manage- 
ment is: 

...to  assist  management  in  achieving  and  documenting,  at 
a  controlled  total  life-cycle  cost,  the  required  perfor- 
mance, realistic  schedule,  operational  efficiency  and 
readiness,  integrated  logistics  support  (ILS) ,  config- 
uration identification  and  interfaces  of  systems,  system 
segments,  equipment,  components,  sub-components,  parts, 
firmware,  computer  programs,  facilities,  and  other  config- 
uration items.  [Ref.  7] 

To  achieve  this  stated  purpose.  Department  of  Defense 
Directive  5010.19  prescribes  uniform  policies  for  configu- 
ration management  within  the  military  services  and  agencies 
of  the  Department  of  Defense  [Ref.  8].   This  directive  requires 
that: 

1.  The  degree  of  configuration  management  applied  to  a 
given  item  be  tailored  consistent  with  the  complexity,  size, 
quantity,  intended  use,  mission  criticality  and  life-cycle 
phase  of  the  item 

2.  Configuration  management  be  applied  to  any  item  devel- 
oped wholly  or  partially  with  government  funding,  immediately 
following  approval  for  full-scale  engineering  development 

3.  Configuration  management  be  applied  to  any  item  wholly 
developed  with  private  funding  and  procured  by  the  government 
upon  procurement  initiation 
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4.  Configuration  management  be  continued  during  the  de- 
ployment/operation/support phases  to  the  extent  required  for 
readiness  support 

DOD  Directive  5010.19  further  directs  each  DOD  component 
head  to  designate  for  specific,  individual  items  or  categories 
of  items,  the  technical  organization  or  individual  having  author- 
ity and  responsibility  for  configuration  management  during 
each  life-cycle  phase  of  the  item  being  procured.   The  DOD 
component  designated  by  the  Secretary  of  Defense  to  have  pri- 
mary responsibility  is  additionally  responsible  for  developing 
and  documenting  interservice  joint  agreements  for  configuration 
management  when  more  than  one  service  is  involved  in  the  acqui- 
sition or  modification  of  an  item. 

B.   CHIEF  OF  NAVAL  tlATERIAL  CONFIGURATION  MANAGEMENT  STATUS 
ACCOUNTING 

Within  the  U.S.  Navy,  the  Naval  Material  Command  (NAVMAT) 
has  been  designated  by  the  Secretary  of  the  Navy  as  the  con- 
figuration office  of  primary  responsibility.   Chief  of  Naval 
Material  Command  Instruction  (NAVMATINST)  4130. lA  and  its  pro- 
posed revision  NAVMATINST  4130. IB  implement  the  configuration 
management  policies  of  DOD  Directive  5010.19.   The  stated  con- 
figuration management  objectives  of  NAVMATINST  4130. lA  are 
to  attain  and  maintain:  [Ref.  7] 

1.   Effective  DOD  component  and  contractor  planning  to 
ensure  that  the  fundamental  elements  of  configuration  manage- 
ment (configuration  identification,  control,  status  accounting 
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and  audits)  are  appropriately  implemented  for  each  config- 
uration item  during  each  phase  of  its  life-cycle 

2.  An  optimum  degree  of  design  and  development  latitude 
coupled  with  the  introduction  of  the  fundamental  elements  of 
configuration  management  at  the  appropriate  time,  degree  and 
depth 

3.  Visibility  of  development  progress  and  compliance  with 
design  requirements  during  the  acquisition  process 

4.  Appropriate  interfaces  and  coordination  within  the 
DOD  and  between  DOD  and  industry 

5.  Maximum  efficiency,  timing,  justification  and  visi- 
bility in  the  processing,  control  and  implementation  of  con- 
figuration changes 

6.  Adequate  and  verified  documentation  and  configuration 
status  accounting  records  to  satisfy  configuration  identifi- 
cation and  overall  program  requirements 

7.  Desired  life-cycle  costs  and  the  required  level  of 
operational  readiness,  supportability ,  interchangeability  and 
interoperability  through  standardization  and  integrated  logis- 
tic support  considerations 

8.  Accurate  and  timely  knowledge  of  the  current  config- 
uration of  the  configuration  item 

NAVMATINST  4130. IB  (Draft),  if  published  as  currently  writ- 
ten, will  require  that  configuration  identification  be  broken 
down  into  three  additional  levels.   These  additional  configura- 
tion levels  will  be  implemented  sequentially  during  the  development 
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of  the  system  and  will  form  the  bases  for  the  Functional, 
Allocated  and  Product  Baselines  represented  in  Figure  3.1. 

The  first  identification  level  proposed  by  NAVMATINST 
4130. IB  (Draft)  is  the  Functional  Configuration  Identification 
which  defines  all  essential  quantitative  and  qualitative  per- 
formance requirements,  interface  constraints,  test  and  eval- 
uation criteria,  and  integrated  logistic  support  parameters 
[Ref .  7] .   The  Functional  Configuration  Identification  is  devel- 
oped by  the  customer  in  conjunction  with  the  contractor  (if 
available)  in  what  NAVMAT  proposes  to  rename  the  Concept  Ex- 
ploration Phase  of  the  system  life  cycle  (The  Concept  Explor- 
ation Phase  is  equivalent  to  the  Comrept  Formulation  Phase 
in  Figure  2.1).   The  Functional  Configuration  Identification 
is  evaluated  at  a  Functional  Requirements  Review  to  determine 
the  adequacy  of  the  functional  requirements  contained  in  it 
and  to  evaluate  the  contractor's  approach  and  completeness. 
Upon  the  completion  of  the  Functional  Requirements  Review, 
the  preliminary  Functional  Configuration  Identification  is 
established,  and  it  becomes  the  basis  for  the  Functional  Base- 
line.  After  its  approval,  the  Functional  Baseline  is  formally 
placed  under  government  configuration  control. 

The  Product  Configuration  Identification  is  the  third  level 
of  the  DOD  configuration  identification  proposed  by  NAVMATINST 
4130. IB  (Draft).   It  "defines  the  CI  in  the  form  of  product, 
material,  and  process  specifications  and  references  documenta- 
tion" [Ref.  7] .   It  is  reviewed  during  the  Critical  Design 
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Review  which  is  held  when  the  detailed  design  of  the  system 
has  been  completed  but  prior  to  its  release  for  prototype 
manufacture  and  test.   The  Functional  Configuration  Identi- 
fication and  Allocated  Configuration  Identification  are  also 
updated  at  this  review.   After  prototype  manufacture,  the 
Functional  Configuration  Identification,  Allocated  Configura- 
tion Identification  and  Product  Configuration  Identification 
are  further  evaluated  in  an  Integrated  Pretest  Review  and  a 
Formal  Qualification  Review.   The  former  determines  whether 
the  system  is  developed  sufficiently  to  undergo  test  and  eval- 
uation, and  the  latter  certifies  that  the  CI  meets  the  contract 
requirements.   The  Product  Baseline  is  then  established  from 
the  Product  Configuration  Identification. 

NAVMATINST  4130.1A  and  NAVMATINST  4 130. IB  (Draft)  provide 
specific  guidance  with  regard  to  configuration  status  accounting 
for  each  phase  of  the  configuration  item's  life  cycle.   During 
the  Concept  Development  Phase,  configuration  status  accounting 
is  limited  to  the  recording  of  all  proposed  changes  to  speci- 
fied functional  and  physical  characteristics.   The  depth  of 
data  to  be  recorded  and  the  scope  and  complexity  of  the  con- 
tractor's configuration  status  accounting  system  is  tailored 
to  correspond  to  the  complexity  of  the  configuration  item. 
Additionally,  all  configuration  status  accounting  data  is  in- 
cluded in  the  contractor's  proposed  Functional  Configuration 
Identification . 
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During  the  Demonstration  and  Validation  Phase  configuration 
status  accounting  is  established  and  maintained  to  record  and 
provide  traceability  of  all  changes  to  the  contractor's  Func- 
tional Configuration  Identification.   Data  recorded  during 
this  phase  of  the  life-cycle  is  additionally  included  in  the 
Allocated  Configuration  Identification  and  is  to  be  of  suffi- 
cient detail  to  aid  in  the  technical  review  process.   Technical 
reviews  are  used  to  determine  if  the  configuration  item  devel- 
opment has  achieved  contract  milestone  requirements.   Addition- 
ally, during  this  phase,  both  the  plan  of  the  office  of  primary 
responsibility  and  the  contractor's  plans  are  to  include  pro- 
visions for  identifying,  continuing  and  expanding  the  config- 
uration status  accounting  system. 

During  the  Full-scale  Development  Phase  the  configuration 
status  accounting  system  identified  in  the  contractor  and  office 
of  primary  responsibility  configuration  management  plan  is 
implemented.   NAVrdATINST  4 130. IB  (Draft)  proposes  that  config- 
uration management  plans  be  revised  during  this  phase  to  record 
and  provide  traceability  of  the  status  of  all  changes  to  the 
Product  Configuration  Indentif ication  as  well  as  the  Functional 
Configuration  Identification  and  Allocated  Configuration  Iden- 
tification.  Additionally  this  instruction  directs  that  the 
configuration  status  accounting  system  implemented  during  this 
phase  be  compatible  with  DOD  standard  configuration  status 
accounting  systems,  planned  technical  reviews,  configuration 
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audits,  and  the  needs  of  management,  acquisition,  evaluation 
production  and  integrated  logistic  support.  [Ref.  7] 

During  the  Production  Phase,  the  configuration  status  ac- 
counting system  developed  during  the  previous  phases  is  further 
expanded  and  refined.   The  office  of  primary  responsibility 
is  tasked  with  adapting  contractor  configuration  status  account- 
ing systems  to  the  DOD  service  (i.e..  Navy,  Air  Force,  etc.) 
standard  system  for  all  configuration  items  not  developed  at 
government  expense.   Upon  configuration  item  deployment,  those 
activities  responsible  for  acquisition,  operation,  test  and 
evaluation  are  directed  to  utilize  the  system  established  by 
the  respective  DOD  service  to  record  and  trace  all  changes 
to  the  configuration  item. 

Finally,  during  the  Deployment  Phase,  the  configuration 
status  accounting  system  implemented  during  the  Production 
Phase  is  utilized. 

NAVMATINST  4130. lA  directs  the  initiation  and  maintenance 
of  a  configuration  record  for  each  configuration  item  upon 
configuration  baseline  establishment.   The  configuration  record 
when  established  consists  of  the  current  configuration  item 
identification  coupled  with  a  history  of  all  configuration 
changes.   The  record  is  maintained  in  a  manner  that  provides 
management  visibility  of  the  configuration  item.   The  reporting 
system  utilized  to  maintain  the  configuration  record  consists 
of  subsystems  for  data  collection  and  data  processing.   Utilizing 
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designated  reporting  sources,  quality  assured  data  and  stan- 
dardized elements,  the  data  collection  system  accumulates 
structured  records  for  data  processing.   The  data  processing 
system  is  engineered  to  provide  timely  and  current  configura- 
tion status  accounting  information  to  user  activities.   Status 
accounting  output  data  requirements  such  as  report  formats, 
level  of  detail,  distribution  and  report  frequency  are  to  be 
of  an  adequate  level  to  meet  management  needs. 

C.   NAVAL  AIR  SYSTEMS  COMMAND  CONFIGURATION  MANAGEMENT 
STATUS  ACCOUNTING 

The  Chief  of  Naval  Material  has  assigned  to  the  Naval  Air 
Systems  Command  (NAVAIR)  overall  responsibility  and  delegated 
it  the  authority  for  management  of  the  configuration  of  Naval 
Air  weapon  system  material  items.   This  responsibility  and 
authority  are  further  assigned  and  delegated  to  the  Director 
of  the  Naval  Air  Systems  Command  Headquarters  Configuration 
Management  Office  which  is  responsible  for  developing  and  main- 
taining policies  and  procedures  governing  the  NAVAIR  Config- 
uration Management  Program.   These  responsibilities  include: 
[Ref.  9] 

1.   Providing  technical  and  administrative  direction  to 
properly  identify,  control  and  record  the  configuration  and 
change  implementation  status  of  the  physical  and  functional 
characteristics  of  aircraft,  weapons,  weapon  systems  and  re- 
lated equipment  throughout  their  life  cycle 


37 


2.  Acting  as  the  primary  NAVAIR  point  of  contact  for  coor- 
dinating configuration  management  matters  and  resolving  asso- 
ciated problem  areas 

3.  Developing,  integrating  and  promulgating  overall  NAVAIR 
policies,  criteria  and  procedures 

4.  Providing  policy  and  administrative  guidance  to  the 
Change  Control  Boards  which  review  and  approve  or  disapprove 
engineering  change  proposals 

5.  Providing  authoritative  direction  and  managerial  assis- 
tance to  functional  groups  and  project  managers  in  implementing 
configuration  management 

6.  Counseling  and  advising  contractors  regarding  config- 
uration management  policies,  plans  and  procedures 

7.  Interfacing  configuration  management  procedures  with 
other  DOD  and  Navy  management  disciplines  (e.g.  Naval  Aviation 
Maintenance  and  Material  Management  System  and  Navy  Integrated 
Logistics  Support  System) 

8.  Establishing  and  maintaining  an  overall  system  for 
processing  and  monitoring  all  configuration  changes 

9.  Developing  and  maintaining  an  aviation  configuration 
status  accounting  system  to  permit  timely  and  accurate  commun- 
ication of  necessary  configuration  data  among  acquisition, 
operational  and  support  activities 

10.  Conducting  continuous  surveillance  of  configuration 
management  to  assure  compliance  and  improve  effectiveness 
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NAVAIR  Instruction  (NAVAIRINST)  4130. lA  implements  NAVMATINST 
4130. lA  and  contains  detailed  guidance,  policy  and  procedures 
governing  Naval  Aviation  configuration  management  responsi- 
bilities assigned  to  the  NAVAIR  Headquarters  Configuration 
Management  Office.   Specifically,  in  the  area  of  configuration 
status  accounting,  NAVAIRINST  4130. lA  identifies  required  con- 
figuration status  accounting  data,  sources  of  data,  config- 
uration status  accounting  systems  and  flow  of  data.   It 
additionally  establishes  guidelines  for  acquisition  of  status 
accounting  data/records/reports  applicable  to  NAVAIR,  its  con- 
tractors, field  activities  and  inventory  control  points.   It 
further  provides  general  guidance  for  physically  marking  con- 
figuration items  for  visual  identification,  which  is  essential 
to  traceability . 

NAVAIRINST  4720. IC  establishes  policy,  responsibility  and 
procedures  for  management  of  modification  materials  procured 
by  or  for  the  Naval  Air  Systems  Command.   The  procedures  out- 
lined in  this  instruction  cover  the  assignment  of  kit  identi- 
fication numbers  and  shipping  instructions,  inventory  management, 
allocation  and  reallocation,  requisitioning,  receipts  and  issues, 
storage,  excesses  and  reclamation.   The  Naval  Aviation  Logistics 
Center  has  been  assigned  by  NAVAIR  as  the  manager  for  the  NAVAIR 
Modification  Program  and  as  manager  for  modification  installa- 
tion support. 
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D.   OTHER  COMMAND  ROLES  IN  CONFIGURATION  MANAGEMENT  STATUS 
ACCOUNTING 

NAVMATINST  5401.2  assigns  the  Naval  Supply  Systems  Command 
as  a  principal  configuration  management  status  accounting  par- 
ticipating activity.   The  Naval  Supply  Systems  Command  is  di- 
rected to  provide  responsive  weapon  systems  file  support  for 
the  Navy's  configuration  status  accounting  system,  a  focal 
point  for  liaison  with  other  system  commands,  and  policy  and 
procedural  support  for  the  Navy's  configuration  status  account- 
ing system. 

NAVMATINST  4130. 5A  establishes  policies  and  assigns  respon- 
sibilities for  Naval  aviation  configuration  status  accounting 
to  fleet  commanders,  type  commanders,  depot  level  maintenance 
activities  and  other  commands  having  custody  of  operational 
and  support  configuration  items.   These  policies  and  assigned 
responsibilities  are  outlined  as  follows: 

1 .  Fleet  Commanders 

a.  Support  and  ensure  that  subordinate  commands  and 
activities  support  configuration  status  accounting 

b.  Require  a  configuration  manager  at  each  level  of 
command 

c.  Ensure  coordination  between  maintenance  and  supply 
functions 

2 .  Type  Commanders 

a.   Implement  and  maintain  a  configuration  status  ac- 
counting system  in  the  fleet 
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b.  Designate  a  configuration  status  accounting  manager 

c.  Ensure  configuration  change  reporting  is  initiated 
by  the  installing  activity  and  submitted  by  the  activity  having 
custody  of  the  configuration  item 

d.  Sponsor  configuration  validations  as  required 

3 .  Depot  Maintenance  Activities 

a.  Report  configuration  changes  accomplished  during 
industrial  maintenance 

b.  Provide  validation  of  configuration  items 

c.  Provide  assistance  to  validation  teams 

4 .  Commands  and  Activities  Having  Custody  of  Operational 
and  Support  Configuration  Items 

a.  Report  configuration  changes  by  submitting  Navy 
configuration  change  data 

b.  Provide  validation  of  configuration  items 

c.  Provide  assistance  to  validation  teams 


41 


IV.   THE  NEED  FOR  CONFIGURATION  MANAGEMENT  STATUS  ACCOUNTING 

A.   IMPORTANCE  OF  CONFIGURATION  MANAGEMENT  STATUS  ACCOUNTING 

From  the  earliest  beginnings  of  an  organized  military, 
weaponry  has  been  modified  to  improve  capability,  reliability 
and  maintainability.   Documentation  of  these  modifications, 
when  accomplished,  has  been  typically  informal  and  non-standard. 
However,  the  increasing  complexity  of  weapon  systems,  the  large 
number  of  dissimilar  items  and  the  high  unit  cost  of  individual 
components  has  led  to  the  development  of  advanced  modification 
and  documentation  systems.   Machine  processing  techniques  have 
enabled  management  to  generate  report  upon  report  in  an  attempt 
to  determine  the  exact  configuration  of  specific  weapon  systems 
at  any  given  moment  in  time.   Unfortunately,  the  majority  of 
these  advanced  configuration  status  accounting  modification 
and  documentation  systems  lack  accuracy,  standardization  and 
centralization. 

The  number  of  modifications  to  weapon  systems  is  on  the 
rise  [Ref.  10].   In  the  Department  of  Defense,  there  is  a  trend 
toward  longer  life  cycles  for  equipment  and  systems,  with  moder- 
nization being  substituted  for  new  procurement  [Ref.  10].   This 
situation  is  exemplified  by  the  aging  and  much  modified  B-52 
bomber  and  F-4  fighter  aircraft. 

As  a  result  of  these  longer  life  cycles,  the  armed  services 
have  experienced  a  large  backlog  of  not  incorporated  modifications 
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In  197  3  it  was  estimated  that  the  Army,  Navy  and  Air  Force 
had  approximately  $304  million  worth  of  kits  on  hand  pending 
installation  [Ref.  10].   This  estimate  did  not  include  any 
modifications  scheduled  for  completion  in  future  years  for 
which  material  had  not  yet  been  procured. 

Further  complicating  the  situation  is  the  fact  that,  even 
with  complex  record  keeping  systems,  the  Navy  is  frequently 
unable  to  determine  with  accuracy  which  modifications  have 
been  accomplished  and  which  have  not  [Ref.  10].   This  leads 
to  improperly  identified  assets,  additional  physical  audits 
which  result  in  wasted  manhours,  duplication  of  effort,  excess 
costs  and  possible  hazardous  conditions. 

The  importance  of  configuration  management  status  account- 
ing does  not  end  with  monetary,  manpower  and  safety  costs. 
Additional  capability  reductions  result  from  the  significant 
time  lag  between  identification  of  functional  problems  with 
a  system  and  implementation  of  corrective  action.   This  sit- 
uation often  results  in  emergency  modifications  to  the  system 
and  hasty  procurement  of  unproven  fixes.   Modifications  that 
have  not  been  fully  tested  frequently  cause  excess  downtime 
due  to  incorporation  difficulties  and  new  deficiencies  caused 
by  the  unproven  modification.   This  type  of  situation  contri- 
butes to  improper  documentation  and  status  accounting. 

One  of  the  most  significant  cost  areas  surrounding  config- 
uration management  status  accounting  concerns  logistic  support 
[Ref.  11].   Prior  to  a  carrier-based  deployment.  Naval  aviation 
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squadrons  are  drawn  from  different  geographic  locations  and 
assembled  onboard  an  assigned  aircraft  carrier.   Once  onboard, 
the  carrier  assumes  full  responsibility  for  the  logistic  sup- 
port of  all  assigned  aircraft.   Since  the  selection  of  aircraft 
scheduled  for  deployment  is  determined  by  the  functional  wing 
at  the  squadron's  home  base,  the  supporting  carrier  depends 
on  a  configuration  input  provided  by  the  functional  wing  and 
airwing  commander.   This  input  is  utilized  to  outfit  the  ship 
with  the  correct  assortment  of  repair  parts,  test  benches, 
support  equipment  and  trained  personnel.   Any  configuration 
differences  between  the  aircraft  provided  and  the  configura- 
tion data  utilized  by  the  ship  directly  results  in  decreased 
operational  readiness,  due  to  a  lack  of  optimal  onboard  support. 
The  importance  of  configuration  management  in  the  Use  Period 
of  a  weapon  system's  life  cycle  is  heightened  since  during 
this  time  hardware  is  largely  in  the  hands  of  the  using  agency. 
Because  these  military  users  are  frequently  far  removed  from 
the  system  developers  in  terms  of  time,  facilities,  personnel, 
communications  and  expertise,  they  are,  out  of  necessity,  fre- 
quently required  to  repair,  modify  and  retrofit  systems  and 
components  without  outside  assistance  under  conditions  of  urgency 

B.   THE  ROLE  OF  CONFIGURATION  MANAGEJIENT  STATUS  ACCOUNTING 

Status  accounting  from  an  operational  sense  is  probably 
the  least  understood  part  of  configuration  management  [Ref. 
12].   It  is  often  perceived  as  a  highly  expensive,  monotonous 
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group  of  reports  utilized  by  management  to  track  modifications. 
Actually,  configuration  management  status  accounting  is  part 
of  a  management  process  that  uses  these  reports  as  a  means 
to  an  end. 

Effective  configuration  management  status  accounting  re- 
quires that  all  changes  be  tracked  from  the  time  the  idea  for 
the  change  is  officially  proposed  and  recorded,  through  its 
investigation  and  evaluation,  until  such  time  as  the  change 
is  disapproved  or  approved.   If  approved,  it  is  further  tracked 
through  its  incorporation  into  the  weapon  system.   This  includes 
tracking  the  incorporation  of  approved  changes  on  the  contrac- 
tor's production  line,  in  operational  units  and  in  spare  units 
located  within  the  logistic  support  system  to  ensure  that  all 
changes  are  accomplished  as  required. 

Additionally,  status  accounting  programs  must  track  iden- 
tification (serial)  numbers  and  document  numbers  for  each  con- 
figuration item  to  ensure  an  adequate  level  of  control.   Programs, 
whether  manual  or  computer  based,  need  to  monitor  the  develop- 
ment of  new/revised  manuals  and  support  equipment  necessary 
to  support  the  change  to  the  product  baseline.   In  the  case 
of  retrofits,  programs  should  track  the  development,  delivery 
and  location  of  modification  kits  and  their  associated  incor- 
poration instructions.   Finally,  configuration  status  account- 
ing must  include  a  routine  to  track  the  configuration  of  all 
units  in  the  field. 
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The  increasing  emphasis  on  lengthening  life  cycles  of  equip- 
ment to  preclude  new  procurement  will  necessitate  more  and 
more  changes  if  systems  are  to  remain  current  with  state  of 
the  art  technology  and  competitive  with  those  potential  ene- 
mies of  the  United  States.   Precise  knowledge  of  equipment 
configuration  obtained  through  effective  status  and  account- 
ing programs  is  vital  to  successfully  achieving  the  required 
equipment  performance,  logistic  support,  system  readiness  and 
operational  efficiency  and  effectiveness  critical  to  warfare 
success . 
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V.       CONFIGURATION   JviATTAGEMENT    STATUS    ACCOUNTING    IN   NAVAIR 

This  chapter  contains  an  overview  of  the  Technical  Direc- 
tive Status  Accounting  (TDSA)  System,  the  Naval  Aviation  Lo- 
gistics Data  Analysis  (NALDA)  System  and  the  interface  between 
the  two  systems.   These  systems  are  prescribed  for  recording 
and  maintaining  modifications  to  equipment  in  the  NAVAIR 
inventory. 

A.   TECHNICAL  DIRECTIVE  STATUS  ACCOUNTING  (TDSA)  SYSTEM 

The  TDSA  System  is  designed  to  encompass  all  weapon  sys- 
tems, missiles,  engines,  trainers,  support  equipment,  and  re- 
pairable components  under  NAVAIR  cognizance  [Ref.  7].   To 
accommodate  this  diversity  of  configuration  items,  the  status 
accounting  system  is  divided  into  four  subsystems.   The  sub- 
system approach  provides  an  economical  means  of  including  the 
entire  NAVAIR  inventory  in  the  configuration  management  pro- 
gram, while  furnishing  NAVAIR  optional  levels  of  data  depth 
based  on  user  requirements  [Ref.  13].   The  four  configuration 
status  accounting  subsystems  are:  Advanced,  Standard,  Installed 
and  Bulk.   Table  5.1  provides  a  breakdown  of  the  four  subsystems 
and  their  specific  applicability,  accounting  standards  and 
identification  methodology. 

The  Advanced  Configuration  Status  Accounting  subsystem 
is  the  most  costly  to  operate  since  it  provides  configuration 
status  of  selected  components  and  support  equipment  by  serial 
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TABLE  5 . 1   NAVAIR  CONFIGURATION 
[Ref.  12] 


STATUS  ACCOUNTING  SYSTEM 


Applicable  To: 


Accounting: 


ADVANCED 
CSA  SYSTEM 


STANDARD 
CSA  SYSTEM 


10%  of  Support 

Equipment 
12%  of  Components 

All  Aircraft 
All  Engines 
10%  of  Support 

Equipment 
10%  of  Components 
All  Trainers 


Standard  CSA  and 
Location  (2nd 
Indenture) 

Unit  Serial 
Number  and  Tech- 
nical Directive 
Status 


INSTALLED 
CSA  SYSTEM 


BULK 
CSA  SYSTEM 


10%  of  Components 
10%  of  Airborne 

Armament 
12  Aircraft  Models 
10%  of  Support 

Equipment 

70%  of  Support 

Equipment 
63%  of  Components 
90%  of  Airborne 

Armament 


Mission/ System 
Capability 


FSN/Part  Numbers 
&  Manufacturer's 
Code 
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number  and  location.   It  has  the  potential  to  identify,  for 
example,  a  specific  squadron  aircraft  bureau  number  in  which 
a  specific  serial  number  identified  component  is  installed. 
As  indicated  in  Table  5.1,  the  use  of  this  subsystem  is  limi- 
ted due  to  the  significant  resources  required  to  support  its 
operation. 

The  Standard  Configuration  Status  Accounting  Subsystem 
records  the  incorporated  or  not  incorporated  status  and  appli- 
cability of  technical  directives  against  specific  bureau  num- 
bers or  configuration  item  serial  numbers.   This  subsystem 
provides  the  means  to  match  listings  of  not  incorporated  tech- 
nical directives  against  baseline  records  for  each  configuration 
item.   This  capability  supplies  management  with  the  basic  data 
necessary  to  manage  technical  directive  change  kits,  technical 
directive  incorporation  workload  scheduling  and  configuration 
item  mission  capability. 

The  Installed  Configuration  Status  Accounting  Subsystem 
provides  configuration  status  accounting  for  selected  systems 
within  a  weapon  system.   In  this  subsystem  selected  systems 
are  coded  by  capability  and  compatibility  for  inventory  and 
support  requirement  management  purposes.   Selection  of  systems 
for  inclusion  in  the  installed  subsystem  is  based  on  the  fol- 
lowing criteria:  [Ref.  7] 

1.  Mission  and  safety  importance 

2 .  Unusual  support  requirements  due  to  complexity  or  spare 
part  shortages 
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3.  Potential  for  frequent  updating 

4.  Number  of  different  configurations  possible  on  like 
model  aircraft 

The  Bulk  Configuration  Status  Accounting  Subsystem  pro- 
vides configuration  management  for  those  configuration  items 
not  included  in  the  previous  subsystems.   This  system  provides 
a  summary  of  the  incorporated/not  incorporated  status  of  each 
technical  directive  applicable  to  each  item  in  the  subsystem. 
Being  the  most  economical  to  operate,  this  subsystem  contains 
the  majority  of  NAVAIR  configuration  items,  as  indicated  in 
Table  5.1. 

The  Configuration  Status  Accounting  System  utilizes  uniform 
record  formats  which  consist  of  baseline  listings,  and  stan- 
dard configuration  status  accounting  elements.   Identification 
of  status  accounting  elements  and  their  related  data  items 
is  contained  in  Military  Standard  482A.   Generally,  baseline 
records  are  initially  acquired  through  contract  requirements 
for  development  and  production  products.   Once  acquired,  con- 
figuration item  baseline  records  are  maintained  at  the  Naval 
Air  Technical  Services  Facility,  Naval  Aviation  Logistic  Center, 
NAVAIR  Designated  Overhaul  Point,  Cognizant  Field  Activity 
and  at  the  Designated  Field  Activity. 

Accountability  of  technical  directives  issued  and  incor- 
porated was  previously  maintained  through  both  the  Technical 
Directives  Master  Data  File  by  the  Naval  Air  Technical  Services 
Facility  and  the  Configuration  Status  Accounting  System  by 
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the  Naval  Air  Systems  Coiranand.   In  an  effort  to  reduce  redun- 
dant efforts  and  duplicate  data  bases,  and  to  provide  more 
current  and  credible  information,  the  Technical  Directives 
Master  Data  File  and  Configuration  Status  Accounting  System 
were  combined  into  the  Technical  Directive  Status  Accounting 
(TDSA)  System  [Ref .  7] .   The  TDSA  data  base  contains  only  data 
supported  by  formal  documentation  and  can  be  changed  only  be 
issuance  of  amended  or  revised  technical  directives.   Chief 
of  Naval  Operations  Instruction  4790. 2B  establishes  the  poli- 
cies, procedures  and  responsibilities  for  the  Naval  Aviation 
Maintenance  Program.   Data  from  the  Maintenance  Data  Collec- 
tion System  of  the  NAMP  is  used  in  the  TDSA  system  for  record- 
kng  technical  directive  compliance. 

TDSA  data  bases  contain  data  describing  attributes  of  Naval 
Air  Systems  Command  technical  directives  such  as  category, 
issue/rescission  dates,  applicable  equipment,  kits  required, 
planned  maintenance  level,  work  unit  code,  applicable  engi- 
neering change  proposal,  and  configuration  control  board  in- 
formation.  In  addition  to  detailed  records  for  each  NAVAIR 
technical  directive,  TDSA  data  bases  contain  equipment  records 
for  all  Naval  aircraft  and  aircraft  engines  which  describe 
the  incorporation  status  of  applicable  technical  directives. 
There  is  one  TDSA  data  base  for  aircraft,  one  for  engines, 
and  one  for  components  and  support  equipment.   In  addition, 
TDSA  provides  projected  and  actual  manhour  reporting,  con- 
figuration status  of  configuration  items,  change  kits, 
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material  accounting,  and  summary  reporting  for  overall  tech- 
nical directive  management  and  budgeting.   The'  system  is  op- 
erational on  a  centrally  located  computer  which  is  accessible 
through  the  geographically  dispersed  terminal  network  illus- 
trated in  Figure  5.1. 

The  diverse  type  of  equipment  within  NAVAIR's  inventory 
requires  different  types  and  degrees  of  management  reports 
for  managing  the  modification  program.   To  provide  an  effec- 
tive yet  economical  method  for  furnishing  this  data,  the  re- 
ports listed  in  Table  5.2  have  been  tailored  and  standardized 
to  provide  desired  information  to  meet  user  requirements.   Each 
TDSA  data  base  is  structured  on  a  Technical  Directive/Appli- 
cability file,  a  Reference/Incorporated  file  and  a  History 
file.   All  three  of  these  files  are  maintained  and  are  acces- 
sible to  all  customers  concerned  with  NAVAIR's  modification 
programs  as  long  as  the  equipment  remains  in  NAVAIR's  inventory 

The  Technical  Directive/Applicability  file  is  established 
and  maintained  by  the  Naval  Air  Technical  Service  Facility 
on  technical  directives  approved  by  NAVAIR.   The  Reference/ 
Incorporated  file  is  established  and  maintained  by  the  Naval 
Aviation  Logistics  Center  and  the  Naval  Aviation  Maintenance 
Training  Group.   These  commands  are  responsible  for  ensuring 
that  all  technical  directive  changes  reported  are  accurately 
reflected  as  incorporated.   A  history  file  is  created  and  main- 
tained by  the  Naval  Aviation  Logistic  Center  and  contains  all 
technical  directives  that  have  been  rescinded  or  cancelled. 
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TABLE  5.2   TDSA  USER  REPORTS  AVAILABLE  [Ref.  14] 


LSTOl     List  of  all  TDs  and  their  effectivity  ranges 

LST02      List  of  serial  numbered  items  showing  NINC  TDs 
applicable  to  each 

LST04     List  of  serial  numbered  items  showing  the  INC 
TDs  for  each 

LST04H    List  of  serial  numbered  items  showing  the  INC 
TD  history  data  for  each 

LST06      List  of  serial  numbered  items  showing  both  the 
INC  and  NINC  TDs  for  each 

LST07     List  by  TD  of  the  serial  numbered  item  for  which 
the  TD  is  applicable  indicating  the  INC  or  NINC 
status  for  each  S/N 

LST20      List  of  serial  numbered  items  and  selected  infor- 
mation about  each 

LST201     Summary  information  on  the  INC  and  NINC  TDs  by 
serial  number 

LST301     Summary  listing  of  TDs  showing  INC  and  NINC 
statistics  for  each 

NAOOl      (TD  Number  Assignment  Report) :  Provide  a  summary 
report  of  TDs,  kits,  and  man-hours  by  type  equip- 
ment code  and  series  for  aircraft  and  engines, 
and  by  TD  code  for  components 

NA002      (Aircraft  Norm  Report) :  TD  calculated  NINC  manhour 
norms  for  a  given  number  of  items  of  a  given  type 
of  equipment 

NA003      (Modification  Summary  Report) :  Provides  matrices 
of  INC/NINC  TDs  by  serial  numbers 

NATOl      (Aeronautical  Technical  Directive  Index — Format  1) 
List  of  TDs  in  the  sequence  of  the  TD  file  with 
selected  information  about  each  i.e.,  CCB  and  ECP 
number 

NATlO      (NAVAIR-00-500C  Report) :  Lists  selected  TDs  appli- 
cable to  a  type,  model,  series  aircraft 
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TABLE  5.2   (Continued) 


NATll      Complete  list  of  all  information  applying  to  a  TD 
that  is  in  the  TD/Applicability  Files 

REP21      (Reference  File  Listing) :  Complete  list  of  all  data 
applicable  to  select  serial  numbered  items  including 
INC/NINC  TDs 
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The  history  file  was  established  to  reduce  active  file  volume 
and  operating  costs  and  to  provide  a  permanent  record  of  his- 
torical modification  transactions.  [Ref.  14] 

Aircraft  reporting  custodians  (squadrons)  and  their  func- 
tional wings  (staffs)  are  provided  quarterly  summary  reports 
of  all  technical  directive  transactions  applicable  to  aircraft 
under  their  cognizance.   These  reports  are  referred  to  as  the 
TDSA  List  2  and  TDSA  List  4  reports.   The  TDSA  List  2  lists 
all  published  technical  directives  applicable  to  but  not  in- 
corporated in  assigned  bureau/serial  numbers,  and  the  TDSA 
List  4  lists  all  published  technical  directives  applicable 
to  and  incorporated  in  assigned  bureau/serial  numbers.   Fol- 
lowing verification  with  the  previous  listings,  the  newly  re- 
ceived listings  are  maintained  in  the  technical  directive 
section  of  the  aircraft/engine  logbook.   It  is  the  responsi- 
bility of  reporting  custodians  to  report  all  list  omissions 
or  errors  to  the  Naval  Aviation  Logistic  Center  TDSA  Officer 
(Code  242).   Annually,  reporting  custodians  receive  the  TDSA 
List  4H  (Historical  Incorporated  Data)  which,  following  veri- 
fication is  also  maintained  in  the  aircraft/engine  logbook. 
The  TDSA  List  4H  indicates  the  incorporation  status  of  all 
applicable  technical  directives. 

Naval  Air  Rework  Facilities  are  tasked   to  audit  each  air- 
craft/engine during  overhaul  and  correct  all  discrepancies 
found  in  the  TDSA  Lists  2  and  4  on  file  in  the  aircraft/engine 
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logbook.  This  audit  by  depot  facilities  was  implemented  to 
provide  a  stable,  consistent  and  reliable  means  of  ensuring 
data  accuracy  throughout  the  fleet.  [Ref.  14] 

B.   NAVAL  AVIATION  LOGISTICS  DATA  ANALYSIS  (NALDA)  SYSTEM 

In  1970,  the  Naval  Aviation  Logistics  community  recognized 
that  all  of  the  elements  of  the  logistics  network — repair  parts, 
support  equipment,  personnel  skills,  technical  data  and  facil- 
ities must  be  considered  together  because  of  their  close  rela- 
tionship and  interdependence  [Ref.  15].   In  recognition  of 
this  requirement,  the  concept  of  the  Naval  Aviation  Logistics 
Data  Analysis  (NALDA)  system  was  formulated.   The  central  ob- 
jective of  the  NALDA  system  is  to  provide  a  significantly  im- 
proved logistics  data  analysis  capability  to  support  the  NAVAIR 
Headquarters,  fleet  type  commanders  and  field  activities  in- 
volved in  the  analysis  and  management  of  logistics  and  engi- 
neering [Ref.  15].   NALDA  has  achieved  this  objective  by  providing 
a  "state-of-the-art"  NAVAIR  corporate  data  base  system  tailored 
to  support  various  NAVAIR  logistic  management  information  sys- 
tems, user  data  analysis  programs,  and  interactive  query 
requirements . 

The  NALDA  prototype  system  first  became  operational  in 
May  1975,  and  was  a  major  step  in  total  system  development. 
The  prototype  demonstrated  that  integrated  application  pro- 
grams and  interactive  data  analysis  can  enhance  material 
readiness,  safety  and  resource  allocation  [Ref.  15].   NALDA 
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moved  from  prototype  to  Phase  1  operational  capability  in 
October  1981  with  the  following  system  applications: 

1.  Analytical  Maintenance  Program  Analysis  Support  System — 
a  tool  to  support  reliability  centered  maintenance  concepts 

2.  Aviation  Maintenance  Engineering  System — a  tool  to 
increase  operational  readiness  by  correcting  maintenance  and 
supply  problems 

3.  TDSA — a  tool  to  manage  the  incorporation  of  technical 
directives  in  aircraft,  engines,  components  and  ground  support 
equipment.   This  system  provides  a  duplicate  data  base  that 
can  be  directly  accessed  by  user  activities. 

NALDA  Phase  II  will  incrementally  incorporate  numerous 
additional  programs  during  fiscal  years  1982  through  1985. 
Programs  for  Phase  II  incorporation  which  have  impact  on  con- 
figuration management  status  accounting  are:  [Ref.  15] 

1.  Engine  composition  and  tracking — a  program  to  project 
and  track  material  and  workload  requirements  for  serial  num- 
bered engines  and  critical  engine  components 

2.  Engineering  change  proposal,  tracking  and  evaluation — 
a  program  to  monitor  and  evaluate  all  engineering  change  pro- 
posals from  inital  action  by  the  NAVAIR  change  control  board 
to  ultimate  disposition,  including  their  installation  as  tech- 
nical directives 

3.  Configuration  management  serial  number  accounting  and 
tracking — a  system  to  track  and  manage  the  configuration  status 
of  aviation  weapon  systems  to  support  NAVAIR  application  programs 
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4 .   Kits  management  information  system — a  program  to  track 
the  location,  quantity  and  condition  of  technical  directive 
change  kits 

Since  NALDA  is  an  analysis  system  and  not  a  data  collec- 
tion system,  it  imposes  no  additional  data  reporting  burdens 
on  the  fleet.   NALDA  receives  maintenance,  supply,  configura- 
tion, operations,  material,  safety,  readiness  and  other  logis- 
tics data  from  existing  data  collection  systems  such  as  the 
Maintenance  Data  Collection  System,  the  Naval  Aviation  Main- 
tenance Program,  the  Aviation  Supply  Office,  Master  Data  File, 
Weapons  System  File,  Naval  Air  Rework  Facilities  and  many  other 
sources  as  indicated  in  Figure  5.2. 

This  data  is  entered  into  a  centrally  integrated  data  bank 
organized  using  a  data  base  management  system  named  System 
2000.   The  System  2000  query  language  makes  it  possible  for 
non  programmers  to  communicate  directly  with  the  computer. 
The  principal  function  of  the  System  2000  data  base  manage- 
ment system  is  to  edit  and  organize  input  data,  then  load  and 
subsequently  update  the  data  bank. 

In  addition,  the  data  base  management  system  can  calculate 
various  summary  and  statistical  data,  develop  graphics,  per- 
form simulations  and  provide  various  modeling  and  forecasting 
outputs,  as  illustrated  in  Table  5.3.   NALDA  is  an  evolution- 
ary management  information  system  which  will  incrementally 
expand  through  subsequent  development  phases  as  new  user  re- 
quirements are  approved  for  incorporation. 
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TABLE  5.3   NALDA  [Ref.  15] 


SYSTEM  2000  DBMS 

*  Natural  Language 
Interactive  Query 

*  Report  Writer 
User  Strings 

*  Cobol,  Fortran,  PLI 


SPECIALIZED  SOFTWARE 

*  Statistics 

*  Graphics 

*  Simulation 

*  Modeling 

*  Forecasting 


APPLICATION  SUBSYSTEM  INTERFACES 


*  AMPAS 

*  AMEN 

*  TDSA 

*  AIMI 

*  VAMOSC-AIR 

*  SM&R-IMP 

*  ICRL-IMP 

*  ECOMTRAK 

*  MPI 

*  SNOAP 


*  SMRA 

*  RIP 

*  DAP 

*  MIR 

*  LSAR 

*  ECP-TRAK 

*  COMSAT 

*  CURES-INT 

*  KITS-MIS 

*  SRC-REP 


USER  COMMUNITY 

MANAGERS 

ENGINEERS 

LOGISTICIANS 

ANALYSTS 
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VI.   LOCAL  CONFIGURATION  MANAGEMENT  STATUS  ACCOUNTING  SYSTEMS 

In  this  chapter  the  deficiencies  of  the  TDSA  and  NALDA 
Systems  are  discussed.   The  overwhelming  necessity  for  real 
time  and  accurate  aviation  maintenance  management  information 
has  lead  to  the  development  of  numerous  independent  systems 
at  various  management  levels  throughout  the  Navy.   (Because 
these  systems  are  not  standardized,  distributed  or  utilized 
on  a  NAVAIR-wide  basis,  they  are  referred  to  as  "local"  sys- 
tems throughout  the  remainder  of  this  thesis.)   Although  highly 
maintenance  management  oriented,  local  systems  often  integrate 
accurate  and  timely  configuration  status  accounting  data  to 
improve  overall  information  system  effectiveness.   Four  local 
systems  representing  specific  airframe,  engine  and  avionic 
applications  are  reviewed. 

A.   TDSA  DEFICIENCIES 

In  December  1978,  following  a  comprehensive  audit  of  the 

NAVAIR  modification  program,  the  Naval  Audit  Service  reported: 

The  TDSA  system,  designed  to  provide  the  current  config- 
uration of  all  Naval  aircraft  and  approved  modifications 
to  be  installed,  is  replete  with  incomplete  and  unrelia- 
ble data.  As  a  result  the  system  output  is  not  reliable 
without  extensive  reconciliation.  [Ref.  16] 

As  part  of  this  evaluation,  the  Naval  Audit  Service  reviewed 

the  NAVAIR  Technical  Directive  Application  File  for  airframe 

changes,  updated  through  31  December  1977.   The  Application 

File  contained  14,832  records  of  which  5,983  involved  kit 
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installations  either  already  incorporated  or  to  be  incorporated. 
Using  computer  aided  analysis,  the  Naval  Audit  Service  found 
the  following  deficient  areas: 

1.  Missing  Data.   Thirty-five  percent  of  the  14,832  records 
were  lacking  manhour  accounting  data  and  thirty-two  percent 

of  the  5,983  records  concerned  with  kit  installations  were 
lacking  cost  accounting  data. 

2.  Unreliable  Data.   Of  the  14,832  records  reviewed,  7,757 
(fifty-two  percent)  had  actually  been  rescinded;  however,  only 
1,833  (twelve  percent)  of  the  TDSA  records  were  identified 

as  being  rescinded.   Records  indicated  that  207,355  modifi- 
cation kits  had  been  incorporated.   However,  only  49,329  kits 
were  actually  recorded  as  having  been  procured.   Additionally, 
a  review  of  aircraft  inspections  (bulletins)  revealed  a  quan- 
tity of  348  kits  incorporated,  despite  the  fact  that  these 
inspections  do  not  require  kits.   Finally,  a  comparison  of 
records  indicating  the  total  number  of  "equipment  items  affected" 
with  records  indicating  total  number  of  technical  directives 
incorporated/not  incorporated  revealed  211,093  units  affected 
and  256,109  incorporated/not  incorporated  technical  directives, 
an  error  of  eighteen  percent. 

Although  the  above  examples  are  few  in  number,  they  repre- 
sent the  magnitude  of  the  problem  that  still  exists  today. 
In  1982,  the  Naval  Audit  Service  reported  that  the  Naval  Air 
Systems  Command  and  Naval  Supply  Systems  Command  "still  have 
not  agreed  on  how  to  carry  out  and  implement  a  configuration 
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status  accounting  program  and  that  management  within  the 
Department  of  the  Navy  has  not  resolved  the  problem."  [Ref. 
17]   It  further  stated  that  the  continued  lack  of  accurate, 
complete  and  timely  configuration  information  is  adversely 
affecting  fleet  operations,  modification  kit  inventory  man- 
agement, depot  maintenance  and  supply  support  within  the  Naval 
aviation  community. 

Naval  operating  forces  are  becoming  increasingly  concerned 
about  system  performance  degradation  resulting  from  config- 
uration errors.   Commander,  Naval  Air  Force,  U.S.  Atlantic 
Fleet  studied  fifty-eight  configuration  related  mishaps  that 
occurred  during  the  eighteen  month  period  ending  30  June  1978. 
The  study  found  that  the  Navy  incurred  over  $100  million  in 
aircraft  damage  during  that  period  as  a  result  of  inadvertant 
aircraft  component  removal,  change  removal,  installation  of 
incompatible  replacement  components  and  failure  to  incorporate 
authorized  changes.  [Ref  16] 

A  study  conducted  by  the  Fleet  Material  Support  Office 
in  1980  revealed  that  aviation  consolidated  allowance  parts 
lists  for  recently  deployed  F-14  squadrons  did  not  authorize 
twenty-five  percent  of  the  required  parts  [Ref.  18] .   The  lack 
of  complete,  accurate  and  timely  configuration  status  account- 
ing data  contributed  significantly  to  these  problems  [Ref.  18]. 

Although  the  Naval  Aviation  Logistics  Command  Management 
Information  System  (NALCOMIS)  is  being  designed  to  provide 
Naval  aviation  activities  with  an  automated  configuration  status 
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accounting  system,  there  is  no  credible  schedule  indicating 
when  NALCOMIS  will  be  implemented.   This,  coupled  with  the 
inadequacies  of  current  information  systems,  has  forced  air- 
craft maintenance  managers  at  all  levels  to  take  aggressive, 
independent  action  to  obtain  or  produce  local  systems  that 
improve  their  control  over  configuration  management. 

Special  purpose  management  information  systems  are  addi- 
tionally created  because  it  is  often  less  expensive,  easier, 
and  faster  to  construct  a  new  system  than  to  correct  existing 
systems  or  accelerate  implementation  of  planned  systems.   In 
many  cases,  managers  simply  cannot  or  will  not  wait  for  a  pro- 
perly planned  and  implemented  management  information  system. 
In  other  cases,  limitations  in  the  budget  process  encourage 
proliferation.   Although  the  limited  cost  of  a  specialized 
system  to  satisfy  a  single  project  is  easily  justified,  rede- 
sign of  existing  systems  is  sometimes  more  cost-effective  and 
results  in  a  system  with  implicit  integration. 

Local  systems  range  from  personal  hardware  and  software 
to  sophisticated.  Navy  funded,  contractor  supported  systems. 
With  few  exceptions,  these  systems  are  not  compatible  with 
each  other  or  NALCOMIS,  and  they  are  not  standardized  in  any 
way.   Although  numerous  systems  exist.  Table  6.1  is  a  listing 
of  those  configuration  management  related  local  systems  cur- 
rently recognized  by  the  Navy.   The  remainder  of  this  chapter 
discusses  four  significant  local  systems  that  have  been 
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TABLE  6 . 1   LOCAL  CONFIGURATION  STATUS  ACCOUNTING  SYSTEMS 


MAINT  LEVEL/ 

ACRONYM 

SPONSOR (S) 

CONTRACTOR (S) 

FUNCTION 

SIDMS 

CNAL 

PRD 

I/SSC 

ARMS 

MAG  14/ 
NAVAIR 

PCI 

0/I/SSC 

FAMMS 

NAVSUP/ 
TYCOMS 

NAVY 

I/SSC 

AMS 

NAVMAT 

CACI/IBM 

O/I 

Measure 

NAVAIR 

CERBERONICS/ 
DELPHI 

I 

TMS 

NAVAIR 

MAC AIR 

ADPE/FMF 

CMC 

UNK 

O/I  Partial 

TICS 

NAVAIR 

NAVY 

LMIS 

NALC 

SAI 

IMRL 

ATSS 

OPNAV 

SYSCON 

Training 
Personnel 
Asset  Mgt 

LINDA 

CNAP 

SYSCON 

General 

SPORT 

CNAL/ 
OCEANA 

WANG 

SSC 

*  VAMP 

CNAP/ AIMS 0 

Mantech 

VAST  Mgt 

*  CMIS 

CNAP 

GRUMMAN 

0 

*  ECOMTRAK 

NAVAIR/ 
NALC 

VSE 

O/I 

*  CAMS/ 

CNAL 

SYSCON 

0 

PLS 

Reviewed  in  this  chapter 
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developed  to  independently  manage  configuration  of  avionics 
equipment,  airframes  and  engines. 

B.   VERSATILE  AVIONICS  SHOP  TEST  (VAST)  AVIONICS  MANAGEMENT 
PROGRAM  (VAMP) 

The  TDSA  system  currently  provides  no  capability  for  track- 
ing changes  to  avionics  weapon  replaceable  assemblies  incor- 
porated at  the  intermediate  or  depot  maintenance  levels. 
Although  data  recording  these  changes  is  entered  in  the  Main- 
tenance and  Material  Management  System  in  the  same  way  that 
airframe  change  incorporations  are  entered,  the  Naval  Aviation 
Logistics  Center  produces  no  consolidated  list  for  avionics 
changes  that  are  equivalent  to  the  airframe  change  List  2  and 
List  4.   Likewise,  avionics  change  incorporation  information 
is  not  available  through  NALDA.   Because  the  maintenance  data 
collection  system  does  not  have  the  capability  to  track  avionics 
components  by  serial  number,  avionics  technical  directive  in- 
corporations are  tracked  only  be  numbers  of  change  kits  docu- 
mented as  having  been  used.   Consequently,  each  intermediate 
maintenance  activity  has  devised  and  pursued  its  own  system 
for  component  serial  number  configuration  status  accounting. 
Due  to  the  magnitude  and  complexity  of  the  task,  most  of  these 
systems  are  manually  tracked  within  the  workcenter  that  incor- 
porates the  change  in  the  specific  piece  of  avionics  equipment. 
However,  one  area  where  a  computerized  system  has  been  developed 
is  in  those  workcenters  where  the  weapon  replaceable  avionics 
assemblies  are  repaired  on  the  Versatile  Avionics  Shop  Test 
(VAST)  bench.  g-7 


Versatile  Avionics  Shop  Test  is  a  computer  controlled  test 
system  designed  to  be  used  by  intermediate  and  depot  level 
aviation  maintenance  activities.   VAST  is  composed  of  a  group 
of  independent,  general  purpose  stimulus  generator  and  mea- 
surement instruments  called  building  blocks  that  are  necessary 
to  test  highly  sophisticated  avionics  equipment.   Because  of 
building  block  independence,  VAST  stations  can  be  readily  adapted 
to  support  a  wide  variety  of  present  and  future  avionics  systems. 

Growing  interest  in  and  increased  utilization  of  automatic 
test  equipment,  coupled  with  concern  over  avionics  equipment 
configuration  management  has  resulted  in  development  of  a  pro- 
totype automated  VAST  management  program  by  Mantech  Corporation. 
The  VAST  Automated  Management  Program  (VAMP)  currently  being 
prototyped  has  the  following  specific  objectives:  [Ref.  19] 

1.  Decrease  weapon  replaceable  assembly  (WRA)  turn-around 
time  through  better  utilization  of  shop  replaceable  assembly 
(SRA)  pool  and  other  assets  awaiting  parts 

2.  Decrease  the  required  management  manhours  to  track 
WRA  run  selection  parameters  allowing  more  time  for  direct 
supervision 

3.  Decrease  techniciam  manhours  expended  on  paperwork 
allowing  more  time  for  WRA  production 

4.  Provide  serial  number  tracking  of  VAST  building  blocks, 
VAST  supported  WRAs  and  VAST  supported  SRAs 

5.  Increase  identification  of  VAST  supported  problem 
components 
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6.  Improve  configuration  management  of  VAST  supported 
weapon  replaceable  assemblies 

7.  Increase  utilization  of  VAST  station  hardware  through 
more  efficient  control  of  station  configuration 

8.  Collect  station  information  for  "real  time"  trend  anal- 
ysis useful  in  detecting  problem  areas,  or  identifying  compo- 
nents which  require  special  attention 

9.  Reduce  documentation  data  errors  through  the  use  of 
automatic  verification  routines  within  the  system 

Currently  VAMP  divides  VAST  operations  into  four  main  func- 
tional areas:  1)  supervisory  function  programs,  2)  maintenance 
action  form  processing,  3)  station  status  programs  and  4)  parts 
availability  programs.   As  these  objectives  indicate,  VAMP 
is  more  than  just  a  configuration  status  accounting  system. 
However,  only  those  methods  and  procedures  generally  dealing 
with  configuration  management  of  avionics  equipment  and  the 
VAST  station  itself  are  addressed  here  with  respect  to  each 
of  these  functional  areas. 

1 .   Supervisory  Functions 

Original  Maintenance  Action  Form  input  to  the  VAMP 
system  is  done  through  the  use  of  this  function.   In  addition, 
existing  maintenance  action  form  data  currently  within  the 
system  can  be  modified  or  corrected.   Other  basic  supervisory 
functions  include  ad-hoc  querying  of  maintenance  data  and  ac- 
cessing Preformatted  reports  and  lists. 
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with  regard  to  configuration  management,  this  function 
contains  a  change  monitoring  program  that  automatically  exa- 
mines every  weapon  replaceable  assembly  part  number  and  serial 
number  as  it  is  entered  into  the  system  to  determine  if  an 
avionics  change  needs  to  be  incorporated  in  that  assembly. 
If  a  change  is  required,  the  program  automatically  prepares 
the  maintenance  action  form  and  posts  the  pending  maintenance 
action  to  the  appropriate  files.   This  program  provides  manage- 
ment with  the  capacity  for  real  time  identification  of  the 
exact  configuration  status  of  any  given  VAST  supported  weapon 
replaceable  assembly. 

2 .   Maintenance  Action  Form  Processing 

The  documentation  of  material  to  be  ordered,  including 
avionics  change  kits,  and  the  completion  of  maintenance  action 
forms  is  achieved  automatically  within  this  function.   In  the 
case  of  completed  avionics  changes,  the  incorporation  data 
is  entered  in  the  computer  under  the  appropriate  menu  driven 
option,  and  the  system  prints  the  necessary  data  on  the  proper 
form.   Configuration  status  changes  resulting  from  any  of  these 
actions  are  automatically  posted  to  the  appropriate  files. 

Real  time  status  of  all  outstanding  maintenance  actions 
(including  technical  directive  incorporations)  are  available 
for  verification  or  ad-hoc  status  checks.   Queries  can  be  made 
by  work  unit  code,  status  (i.e.,  awaiting  maintenance,  awaiting 
parts),  part  number,  serial  number,  avionics  change  number 
or  supply  requisition  number. 
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3 .  Station  Status  Programs 

Procedures  for  reporting  the  configuration  of  the  VAST 
system  itself  have  been  incorporated.   VAMP  has  been  designed 
to  track  and  record  station  status  data  for  one  or  all  sta- 
tions.  Before  any  station  status  change  can  be  made  by  the 
operator,  the  VAMP  system  performs  verification  to  ensure  that 
proper  conditions  exist  throughout  the  VAST  system  to  justify 
a  status  change  (i.e.,  station  status  is  not  being  changed 
from  down  to  up  when  there  is  an  outstanding  maintenance  action 
against  the  station) .   This  verification  is  designed  to  ensure 
maximum  data  integrity  of  configuration  identification  within 
the  VAST  system. 

Under  VAMP,  VAST  station  configuration  status  can  be 
quickly  displayed  and  reviewed.   Building  blocks  currently 
installed  in  a  given  station  can  be  identified  to  the  serial 
number  level,  thus  providing  an  accurate  real  time  station 
configuration  tracking  system.   Maintenance  and  supply  actions 
are  automated  for  all  actions  involving  building  blocks.   This 
automated  function  includes  documentation  of  all  removal,  in- 
stallation, cannibalization  and  calibration  actions.   Addition- 
ally, the  system  provides  for  automated  supply  requisition 
and  maintenance /supply  status  change  documentation. 

4 .  Parts  Availability  Programs 

The  ability  to  quickly  determine  the  availability  of 
required  parts  plays  a  significant  role  in  maximizing  VAST 
workcenter  throughput.   As  a  result,  procedures  that  allow 
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parts  availability  to  be  quickly  and  easily  determined  have 
been  incorporated  into  this  function.   The  system  can  be  queried 
to  determine  whether  or  not  a  required  part  or  technical  direc- 
tive change  kit  is  available  for  issue  by  the  supporting  Supply 
Department. 

Another  useful  feature  of  VAMP  with  regard  to  parts 
requirements  and  availability  involves  a  set  of  routines  which 
screen  the  configuration  of  all  awaiting  parts  assets  for  re- 
quired parts.   Rather  than  allow  these  assets  to  remain  unused 
and  send  still  another  unit  to  the  awaiting  parts  locker,  the 
required  parts  can  be  cannibalized  from  a  unit  already  awaiting 
parts  so  that  the  other  unit  can  be  made  ready  for  issue. 

Telephone  discussion  with  VAMP  managers  at  the  prototype 
site  indicates  that  the  VAMP  system  has  significantly  enhanced 
management  of  the  VAST  workcenter  and  configuration  control 
of  the  assemblies  under  VAST  cognizance.   However,  there  is 
no  quantitative  data  available  to  determine  its  actual  level 
of  effectiveness  [Ref.  20].   This  lack  of  data  is  a  result 
of  the  relatively  short  time  VAMP  has  been  in  operation  and 
the  fact  that  it  has  been  tested  at  only  one  site. 

The  major  limitation  currently  impacting  VAST/VAMP 
management  is  supply  support.   The  inventory  data  base  of  re- 
placement parts  and  technical  directive  change  kits  has  not 
been  entered  into  the  system.   Consequently,  VAMP  can  not  deter- 
mine if  a  replacement  part  is  actually  in  stock.   Another 
supply-related  limitation  involves  the  set  of  routines  which 
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search  awaiting  parts  assets  for  needed  parts.   This  feature 
is  utilized  only  eight  hours  per  day  Monday  through  Friday 
because  of  a  shortage  of  supply  personnel.   Since  maximum  uti- 
lization of  the  VAST  station  requires  24-hour  operation,  greater 
access  to  supply  data  could  provide  significant  increases  in 
VAMP  efficiency  and  effectiveness. 

VAMP  provides  an  effective  means  of  monitoring,  con- 
trolling and  accounting  for  avionics  component  configuration. 
Fully  compatible  with  NALCOMIS,  VAMP  is  the  only  automated 
system  in  the  Navy  developed  specifically  to  manage  avionics 
components.   Given  the  lack  of  interface  systems,  VAMP  is  only 
capable  of  tracking  component  locations  when  the  component 
is  physically  within  the  VAST  workcenter.   Additionally,  VAMP 
is  designed  to  manage  only  VAST  supported  components  which 
comprise  a  small  percentage  of  the  total  NAVAIR  avionics  inventory 

The  VAMP  system  is  a  first  generation  management  infor- 
mation system  enhancing  VAST  workcenter  throughput  and  config- 
uration management  of  avionics  weapon  replaceable  assemblies. 
Data  provided  by  VAMP  developers  indicates  that  the  system 
is  currently  being  expanded  to  solve  some  of  the  deficiencies 
and  limitations  discussed  herein  [Ref.  19].   If  provided  with 
upline  reporting  capability  to  NALCOMIS  and  NALDA,  and  if  ex- 
panded to  include  all  intermediate  level  weapon  replaceable 
avionics  assemblies,  VAMP  has  the  potential  to  become  an  even 
more  effective  avionics  configuration  accounting  system.   VAMP 
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may  lead  the  way  to  increased  readiness  by  combining  effective 
decision-making  tools  and  useable  management  information  for 
configuration  status  accounting. 

C.   CONFIGURATION  MANAGEMENT  INFORMATION  SYSTEM  (CMIS) 

The  Configuration  Management  Information  System  (CMIS) 
is  a  computerized  system  designed  to  reflect  the  present  sta- 
tus of  all  major  changes  affecting  supported  aircraft  at  the 
organizational  level.   It  was  developed  by  Grumman  Aerospace 
to  provide  summary  level  information  concerning  configuration 
change  requirements  and  configuration  status  in  the  complex, 
dynamic  environment  of  multiple  aircraft  configurations  at 
multiple  sites  and  overhaul  facilities.   CMIS  provides  a  wide 
variety  of  reports  for  planning  and  management  visibility  which 
highlight  the  remaining  actions  necessary  to  ensure  incorpor- 
ation of  changes  into  all  affected  aircraft.   An  on-line,  single 
source  data  base  accessible  through  a  nationwide  tele-network 
enables  CMIS  to  support  a  wide  variety  of  user  applications 
and  requirements.   The  CMIS  system  utilizes  an  IBM  370  computer 
located  at  Grumman ' s  Bethpage,  New  York  facility.   The  language 
employed  for  the  system  is  ANS  COBOL  Version  4. 

The  functional  system  consists  of  two  separate  data  bases 
(Figure  6.1) :  [Ref .  21] 

1.   Master  Data  Base  with  the  following  capabilities: 

a.  Update  data  contained  within  the  system 

b.  Create  new  reports 
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c.  Control  site  access 

d.  Produce  all  standard/catalogued  reports 

e .  Provide  check  output  option 

2.   Duplicate  Data  Base  with  the  following  capabilities: 

a.  Produce  selected  standard/catalogued  reports 

b.  Provide  check  output  option 

CMIS  design  permits  only  the  users  of  the  Master  Data  Base 
(Grumman)  the  capability  to  develop  new  reports.   Duplicate 
Data  Base  users  (Fleet)  are  permitted  access  to  only  cata- 
logued existing  reports.   Adequate  flexibility,  however,  has 
been  build  into  the  system  to  provide  unique  user  reports  to 
a  specific  user  upon  request. 

Data  input  to  the  Master  Data  Base  is  accomplished  entirely 
by  Grumman  Aerospace  in  Bethpage.   The  Product  Baseline  for 
each  specific  block  of  aircraft  bureau  numbers  is  entered  during 
production  and  updated  during  the  Operations  and  Support  Phase 
with  data  provided  from  user/supported  activities  (Figure  6.2). 
The  CMIS  system  is  operated  independently  from  the  Navy  Main- 
tenance Material  Management  System  and  is  not  designed  to  inter- 
face with  NALDA  or  NALCOMIS.   Update  data  submitted  by  user/ 
supported  activities  is  provided  to  Grumman  on  specially  designed 
formats/reports  or  in  some  cases  on  existing  Navy  report  forms. 

Upon  completion  of  data  inputs/updates  to  the  Master  Data 
Base,  a  transfer  routine  immediately  updates  the  Duplicate 
Data  Base  with  the  latest  information.   Data  is   contained 
or  stored  in  the  Master  Data  Base  in  a  matrix  format.   Each 
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data  address  is  composed  of  change  identification  numbers 
corresponding  to  the  appropriate  engineering  change  proposal 
and  technical  directive  number. 

Once  user  access  has  been  established  through  the  log-on 
procedure  and  telenet  system,  two  menu  driven  options  are  pro- 
vided: Report  Output  and  Check  Output.   Selecting  the  Report 
Output  option  of  CMIS  provides  the  user  access  to  sixty-four 
standard/catalogued  reports  designed  to  aid  in  change  planning, 
identification,  descriptions  and  overall  change  management. 
Table  6.2  provides  a  listing  of  available  reports.   Reports 
are  selected  by  catalogue  number  and  are  formatted  for  high 
speed  printers  with  wide  carriages  (210  characters)  to  provide 
maximum  data. 

Selecting  the  Check  Output  option  of  CMIS  provides  the 
user  with  the  capability  to  compare  a  given  target  baseline 
aircraft  configuration  with  the  "actual"  configuration  of 
another  aircraft  or  group  of  aircraft.   For  example,  assume 
a  deployed  F-14  squadron  onboard  an  aircraft  carrier  in  the 
Indian  Ocean  has  lost  an  aircraft  at  sea  and  that  an  immediate 
replacement  aircraft  of  identical  configuration  is  required. 
The  user  would  simply  select  the  appropriate  target  baseline 
and  input  the  bureau  numbers  of  all  potential  replacement  air- 
craft.  The  Check  Output  option  of  the  CMIS  system  would  iden- 
tify all  differences  between  the  target  baseline  and  actual 
configuration  of  each  potential  replacement  bureau  number  entered, 
thereby  significantly  simplifying  the  selection  process. 
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TABLE  6.2   CMIS  USER  REPORTS  [Ref.  21] 


*  ECPs  IN  PROCESS 

*  ECPs  NOT  REQUESTED 

*  ECPs  REQUESTED  BUT  NOT  SUBMITTED 

*  ECPs  SUBMITTED  BUT  NOT  APPROVED  BY  ACCB 

*  ACPs  APPROVED  BY  ACCB — NO  FORMAL  AUTH  RECEIVED 

*  ECPs  WITH  PRODUCTION  AUTH  AND  NOT  RET  AUTH 

*  ECPs  RETRO  AUTH — ALL  KITS  NOT  ORDERED 

*  PTR  PROGRAM 

*  REDUCED-ECPS  RET  AUTH  NOT  ALL  KITS  ORDERED 

*  ECP  SUMMARY 

*  ECP  NUMBER/ STATUS  SEARCH — QUERY 

*  CHANGE  DESCRIPTION  ECP — QUERY 

*  ACTIVE  ECP  STATUS  SORTED  BY  ECP 

*  RM  &  S  PROGRAM 

*  ACTIVE  CHANGES  BY  CATEGORY — QUERY 

*  CHANGES  BY  RANK — QUERY 

*  ANCILLARY  EQUIPMENT  CHANGES 

*  SELECTED  ANCILLARY  EQUIPMENT  CHANGES — QUERY 

*  TECH  DIRECTIVE  SUMMARY 

*  TECH  DIRECTIVE  NUMBER/ STATUS  SEARCH — QUERY 

*  CHANGE  DESCRIPTION  TD — QUERY 

*  ACTIVE  ISSUED  TECH  DIRECTIVES 

*  CONFIGURATION  DIFFERENCES — ALL  A/C  VS  BASELINE 

*  PRE  DD2  50  TECH  CIRECTIVE  INCORPORATION 

*  TDs  NOT  ISSUED 

*  TITLE  KEY  WORK  SEARCH — QUERY 

*  REMARKS  KEY  WORD  SEARCH—QUERY 

*  SYSTEM  STATUS  SEARCH  QUERY 

*  ACD  NUMBER/ STATUS  SEARCH — QUERY 

*  A/C  18  3  PLUS  SDLM  CHANGES  (SDLM  1) 

*  BLOCK  9  5  PLUS  SDLM  CHANGES  (SDLM  2) 

*  ACD  SUMMARY 

*  CMIS  WEEKLY  NEWS 

*  SELECTED  ECP  EFFECTIVITY  &  INCORP  STATUS 

*  SELECTED  TD  EFFECTIVITY  &  INCORP  STATUS 

*  TIME  COMPLIANCE  REQUIREMENT  TD  INCORPORATION  STATUS 

*  SEL  TD  NOT  INC  BY  SEL  BUNO 

*  SEL  TD  INC  BY  SEL  BUNO 

*  TDs  NOT  INCORP  BY  SELECTED  BUNO 

*  TDs  INCORP  BY  SELECTED  BUNO 

*  CONFIG  DIFFERENCES — SELECTED  BUNO  VS  BASELING — RQD  TDS 

*  TD  NIC  &  PAST  RECISSION  DATE  BY  SEL  BUNO 

*  TCR  TDS  NOT  INC  BY  SEL  BUNO 

*  TD  NIC  BY  SEL  COMPLIANCE  RQMT  &  SEL  BUNO 

*  SEL  TD  NOT  INC  BY  SEL  SQUADRON 
TDs  NOT  INC  WITHIN  SEL  SQUADRON  (BUNO) 
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* 


TABLE  6.2   (CONTINUED) 


*  TDs  NOT  INC  WITHIN  SEL  SQUADRON  (MATRIX) 

*  CONFIG  DIFFS — WITHIN  SEL  SQUADRON — REQD  TDS  (MATRIX) 

*  CONFIG  DIFFERENCES  — SELECTED  SQDN  VS  BASELINE~RQD  TDS 

*  TDs  NIC  &  PAST  RECISSION  DATE  BY  SEL  SQUADRON 

*  TCR  TDS  NOT  INC  BY  SEL  SQUADRON 

*  SEL  TD  NOT  INC  BY  SEL  LOCATION 

*  TDs  NOT  INC  BY  SEL  LOCATION  (BUNO) 

*  TDs  NOT  INC  WITHIN  SEL  LOCATION  (MATRIX) 

*  CONFIG  DIFFS — WITHIN  SEL  LOCATION — REQD  TDS  (MATRIX) 

*  TDs  NIC  &  PAST  RECISSION  DATE  BY  SEL  LOCATION 

*  TCR  TDs  NOT  INC  BY  SEL  LOCATION 

*  SEL  TD  NOT  INC  BY  SEL  SHOP  NOS 

*  TDs  NOT  INC  WITHIN  SEL  SHO  NOS  (MATRIX) 

*  TDs  NIC  &  PAST  RECISSION  DATE  BY  SEL  SHOP  NOS 
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The  CMIS  system  is  an  excellent  configuration  management 
tool  for  use  at  the  functional  wing  or  type  commander  level. 
It  provides  improved  accuracy  over  the  TDSA  system  and  its 
counterpart,  NALDA.   This  is  reflected  in  Table  6.3  which  pro- 
vides CMIS  system  accuracy  figures  as  reported  by  Grumman  Aero- 
space.  Because  CMIS  does  not  depend  on  the  Maintenance  Data 
Collection  System  for  input  data,  it  tends  to  be  fifteen  to 
thirty  days  more  current  than  TDSA  or  NALDA. 

The  CMIS  outputs  are  very  readable  and  display  ample  infor- 
mation in  a  relatively  small  space.   A  sample  output  is  provided 
in  Figure  6.3.   The  number  of  formatted  reports  offered  is 
larae  and  varied  enough  to  accommodate  nearly  all  information 
requirements.   The  system  has  been  successfully  used  at  the 
Commander,  Naval  Air  Force,  U.S.  Pacific  Fleet  Fighter  Class 
Desk  (type  commander)  to  monitor  and  schedule  F-14  depot  main- 
tenance and  deployment  requirements  up  to  five  years  in  advance. 
CMIS  successfully  aggregates  the  configuration  information 
required  by  mid-  and  upper-level  managers  for  making  aircraft 
assignment  and  technical  directive  incorporation  decisions. 

On  the  other  hand,  CMIS  has  the  capability  of  monitoring 
only  those  changes  physically  incorporated  in  the  basic  air- 
frame (airframe  changes) .   It  cannot  track  avionics  changes 
to  weapon  replaceable  assemblies,  powerplant  changes  to  engines 
or  aircrew  system  changes  (e.g.  ejection  seats).   CMIS  is  not 
designed  to  interface  with  NALDA  or  NALCOMIS,  and  it  is  cur- 
rently available  for  only  Grumman  products.   It  creates  a 
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TABLE  6 . 3   CMIS  DATA  BASE 


FIELD 


D  CONTENT  | 

:Ref.  21] 

PERCENT  OF 

ACCURACY  OF 

DATA  INPUT 

INPUT  DATA 

100 

100 

100 

100 

100 

100 

90 

100 

100 

75 

100 

90 

100 

75 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

95 

90 

100 

m 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

25 

100 

100 

100 

100 

100 

100 

100 

100 

100 

ECP  Number 

ECP  Type 

ACD  Number 

TD  Number 

TD  Category 

TD  Issued 

Title 

Usage  Code 

ECP  Requested 

ECP  Submitted 

ECP  Planned/Actual  FY  Funding 

ECP  Proposed  Effectivity 

ECP  Proposed  Authorizarion  Data 

ACCB 

Production  Authorization 

PRB  Number 

First  Production  A/C 

Production  Effectivity 

Block 

Retrofit  Authorization 

First  (Earliest)  Retrofit  A/C 

Retrofit  Effectivity 

Pre  DD-250  TD  Incorporation  A/C 

Kits  Required 

Kits  Ordered 

Projected  TD  Issuance  Date 

Start  TD  Validation 

Complete  TD  Validation 

Start  TD  Verification 

Complete  TD  Verification 

Scheduled  TD  Issuance 

Submittal  of  TD  to  NATSF 

TD  Issuance  Date 

TD  Rescission  Date 

TD  Compliance  Requirement 

Last  Event  Code 

Last  Event  Date 

Next  Event  Code 

Next  Event  Date 
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TABLE  6.3   (Continued) 


PERCENT  OF    ACCURACY  OF 
FIELD DATA  INPUT    INPUT  DATA 

Text  (Description)  10  100 

-  Associated  Changes  10  100 

-  Remarks  10  100 

-  Kit  ID  Numbers  10  100 

-  Other  0  0 
WRA  Part  Number  10  100 
Retrofit  Plan  100  100 
Maintenance  Level  100  90 
Installation  Manhours  100  90 
System  Impacted  100  90 
Mean  Flight  Hours  Between  100  100 

Failure  Delta 
Maintenance  Manhours  per  Flight      10  0  100 

Hour  Delta 
Major  Category  of  Change  100  100 

(Reliability,  Performance) 
Rank  Within  Category 
Deconf igurable  Change 
SDLM  1  Change 
SDLM  2  Change 
Tech  Problem  Review  Item 
Remarks 

Production  A/C  INC/NINC 
Retrofit  A/C  INC/NINC 
Not  Incorporated  Total 
Complete /Disapproved 
A/C  Bureau  Numbers 
A/C  Shop  Numbers 
Squadron  Assignment 
Site  Location 
Carrier  Location 
WRA  Change  Incorporation  Status 


100 

100 

50 

25 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

100 

0 

0 
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duplicate  configuration  status  accounting  data  base  which  must 
be  maintained  and  verified  against  the  TDSA  data  base..  At 
the  present  time,  the  maintenance  of  that  data  base  is  done 
by  Grumman  Aerospace  through  a  contract  with  the  Navy.   This 
arrangement  fails  to  provide  a  timely  method  for  collecting 
data  from  and  supporting  deployed  squadrons  and  carrier  air 
wing  staffs,  since  telenet  is  not  available  to  deployed  car- 
rier based  units. 

CMIS  is  an  effective  contractor-developed,  contractor-run 
system  that  is  valuable  to  Navy  managers.   However,  in  order 
to  fully  benefit  from  CMIS,  the  Navy  must  develop  the  capa- 
bility to  maintain  and  update  the  system  within  its  own  config- 
uration management  information  system  structure. 

D.   ENGINE  COMPOSITION  TRACKING  SYSTEM  (ECOMTRAK) 

Engine  management  presents  numerous  unique  configuration 
related  problems.   For  instance  during  engine  build-up,  fol- 
lowing rework  or  repair,  engine  life-limited  components  must 
be  matched  with  other  components  having  similar  "life  remain- 
ing" in  order  to  optimize  overall  engine  service  life.   Addi- 
tionally, all  components  installed  must  be  matched  for 
configuration  compatibility.   All  applicable  unincorporated 
technical  directives  must  be  identified  and  incorporated  during 
each  overhaul  or  repair,  as  it  is  not  economically  or  opera- 
tionally sound  to  remove  engines  from  operational  or  nonoper- 
ational  aircraft  solely  for  technical  directive  incorporation. 
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In  many  cases  the  incorporation  of  a  technical  directive  alters 
a  component's  "service  life  remaining"  which  in  turn  might 
alter  the  engine's  service  life.   Finally,  engine  components 
are  tracked  by  their  assigned  serial  numbers  and  by  the  engine 
serial  number  in  which  they  are  installed.   On  most  jet  en- 
gines, the  serial  number  plate  is  attached  to  the  main  gear 
box.   If  this  gear  box  is  replaced  and  the  serial  number  plate 
is  not  switched  (a  common  occurrence),  the  configuration  sta- 
tus information  of  the  installed  engine  components  can  become 
quickly  confused  or  invalid. 

Because  the  NAVAIR  Maintenance  Material  Management  system, 
of  which  the  TDSA  system  is  a  part,  does  not  manage  these  com- 
plex problems,  the  Engine  Analytical  Maintenance  Program  was 
developed  to  identify  those  actions  required  to  develop  and 
maintain  engine  composition/configuration  tracking.   Addition- 
ally it  identifies  those  engine  management  functions  to  be 
performed  to  support  reliability  centered  maintenance.   In 
conjunction  with  the  Engine  Analytical  Maintenance  Program, 
the  Automated  Engine  Composition  Tracking  System  (ECOMTRAK) 
is  being  developed  to  provide  on-line  information  necessary 
to  manage  aircraft  engine  configuration  and  maintenance. 

When  implemented,  ECOMTRAK  is  planned  to  be  fully  compat- 
ible with  NALCOMIS  and  will  extract  all  input  data  from  the 
Maintenance  Data  Collection  System  of  the  Maintenance  Material 
Management  System.   The  implementation  of  ECOMTRAK  for  each 
specific  engine  requires  the  performance  of  the  following 
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sequential  events  by  aircraft  engine  support  and  management 
activity  commands: 

Phase  I      Selection  of  items  to  be  tracked 

Phase  II     Tracked  item  data  input 

Phase  III    Engine  composition  data  collection  and 
input  and  ECOMTRAK  file  maintenance 

Phase  IIIA   Depot  implementation 

Phase  IV     Engine  asset  management 

The  ECOMTRAK  System  is  currently  being  developed  and  main- 
tained by  NAVAIR  through  contractor  support.   When  fully  imple- 
mented and  properly  maintained,  ECOMTRAK  will  provide  real 
time  engine  management  information  for  use  as  follows: 

1.  To  project  spare  part  support  requirements 

2 .  To  forecast  intermediate  and  depot  engine  workload 

3.  To  establish  depth  and  scope  of  engine  repair 

4.  To  assist  fleet  operators  with  management  of  component 
life  limits 

5.  To  assist  in  establishment  of  fixed  allowance  lists 

6.  To  determine  the  impact  of  technical  directives 

7.  To  determine  the  impact  of  component  life  limits 

None  of  the  above  tasks  can  be  effectively  accomplished  without 
the  availability  of  up-to-date,  accurate  comprehensive  engine 
configuration  information. 

Within  ECOMTRAK,  reliability-centered  maintenance  analysis 
logic  is  used  to  determine  which  components  to  track.   Other 
items  being  scheduled  for  tracking  include  high  value,  long 
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procurement  lead  time  items  and  items  with  technical  directive 
or  configuration  impact.   Both  repairable  and  consumable  items 
are  being  identified  for  tracking  by  the  application  of  Mili- 
tary Standard  266  Reliability  Centered  Maintenance  logic. 

Data  sources  being  utilized  for  ECOMTRAK  file  construction 
include  maintenance  plans,  illustrated  parts  breakdowns,  tech- 
nical directives,  engineering  change  proposals,  local  instruc- 
tions, engine  logbooks  and  planned  maintenance  requirements 
for  each  specific  type/model/series  engine.   After  initial 
data  entry,  data  base  maintenance  is  accomplished  at  the  orga- 
nizational and  intermediate  levels  by  continuous  entry  of  main- 
tenance actions  (including  technical  directive  incorporation) , 
flight  activity  data,  custody  change  data  and  depot  maintenance 
data.   A  visual  representation  of  the  update  process  is  depicted 
in  Figure  6.4. 

Unlike  most  of  the  existing  configuration  management  pro- 
grams in  the  Navy,  ECOMTRAK  is  not  a  stand  alone  system.   It 
has  been  designed  to  interface  directly  with  the  TDSA  system 
and  NALDA  and  is  completely  compatible  with  NALCOMIS.   When 
fully  implemented,  ECOMTRAK  is  designed  to: 

1.  Track  all  engine  parts  by  serial  number  providing 
location  and  condition 

2.  Generate  reports  that  provide  data  on  available  parts 
for  best  match  engine  build-up 

3.  Automate  engine  build-up  data  collection 
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4.  Automatically  screen  all  data  for  correct  application 

5.  Automatically  produce  all  engine  logbook  records 

6 .  Automatically  update  the  TDSA  engine  data  bank 

7.  Provide  current  technical  directive  Lists  02  and  04 
for  each  processed  engine 

8.  Produce  a  scrap  parts  file 

9 .  Automate  parts  ordering 

10.  Produce  preformatted  reports  identified  in  Table  6.4. 

TABLE  6 . 4   ECOMTRAK  REPORTS 

*   ENGINE  REPORTS 

*  Engine  Status  Report 

*  Critical  Components  Tracking  Report 

*  Engine  Associated  Critical  Component  Status  Report 

*  Engine  Hard  Time  Report 

*  Fleet  Component  Rejections  Projected  Report 

Although  ECOMTRAK  is  still  in  the  development  phase,  it 
has  the  potential  to  significantly  enhance  engine  configuration 
management  by  providing  engine /component  serial  number  tracking 
With  the  advent  of  ECOMTRAK,  all  of  the  required  data  on  any 
given  engine  will  be  available  in  an  accurate,  accessible  for- 
mat at  the  management  level  where  it  is  required. 
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E.   PORTABLE  LOGISTIC  SYSTEM  (PLS) 

The  Portable  Logistic  System  (PLS)  is  a  Coinmander,  Naval 
Air  Force,  U.S.  Atlantic  Fleet  (CNAL)  initiative  designed  to 
provide  an  improved  aircraft  maintenance  management  informa- 
tion system  at  the  squadron  level.   It  is  a  functional  exten- 
sion of  and  logical  outgrowth  from  several  existing  automated 
systems — the  Aviation  Training  Support  System,  the  Resource, 
Configuration  and  Scheduling  Subsystem  and  the  Comprehensive 
Asset  Management  System  [Ref.  22].   The  Aviation  Training  Sup- 
port System,  which  is  designed  and  installed  as  a  dedicated 
training  system,  contains  a  subsystem  defined  as  Resource, 
Configuration  and  Scheduling  which  was  designed  to  match  air- 
crew and  syllabus  training  assignments  with  a  correctly  con- 
figured aircraft.   The  Comprehensive  Asset  Management  System 
was  developed  from  the  Resource,  Configuration  and  Scheduling 
subsystem  to  maintain  configuration  data  on  and  status  of  air- 
craft, engines  and  other  selected  aeronautical  equipment. 

PLS  is  designed  to  be  a  distributed  processing  system  with- 
in functional/carrier  air  wing  organizations.   At  each  geographic 
location,  both  ashore  and  afloat,  PLS  provides  communication 
facilities  for  remote  data  entry  and  data  query.   Squadrons 
communicate  via  cable/f iberoptics  with  colocated  functional/ 
carrier  air  wings.   Although  PLS  provides  for  remote  access 
capability  by  higher  level  managers  such  as  Commander,  Naval 
Air  Force,  U.S.  Atlantic  Fleet  when  both  activities  are  shore- 
based,  communication  between  ashore  and  afloat  units  is  restricted 
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The  distributed  PLS  system  is  configured  with  minicomputer 
central  processing  units,  mass  storage  and  input/output  de- 
vices.  A  typical  squadron  allocation  of  hardware  is  depicted 
in  Table  6.5,  and  a  typical  functional  wing  and  carrier  air- 
wing  hardware  allocation  is  tabulated  in  Table  6.6. 

Each  squadron  system  supports  the  functional  requirements 
of  squadron  users.   Certain  data  are  provided  on  a  routine 
basis  to  the  functional  wing  system  ashore  or  carrier  airwing 
system  afloat  depending  on  squardron  location.   The  wings  then 
exchange  data  between  carrier  and  shore  location  for  updating 
specific  aircraft  and  personnel  training  data  bases.   This 
distributed  design  concept  is  depicted  in  Figure  6.5.   PLS 
fundamentally  uses  a  two  level  hierarchical  design  configura- 
tion.  The  design  is  hierarchical  in  that  data  is  originated 
at  the  squadron  and  relayed  to  the  wing  system  for  the  pur- 
pose of  data  backup  and  information  exchange.   The  distributed 
feature  of  PLS  allows  squadron  systems  to  function  even  in 
the  event  of  a  functional/carrier  air  wing  system  failure. 

Because  PLS  is  not  compatible  with  NALCOMIS,  its  expected 
life  will  depend  on  NALCOMIS  implementation.   PLS  will  be  ter- 
minated when  NALCOMIS  becomes  operational  at  each  PLS  site. 
Although  not  specifically  planned  within  the  PLS  concept,  data 
can  be  supplied  directly  to  systems  such  as  TDSA  or  the  Engine 
Analytical  Maintenance  Program. 
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TABLE  6 . 5   PLS  SQUADRON  HARDWARE  ALLOCATION 


QUANTITY  DESCRIPTION 

1  PDF  11/23  CPU,  256  KB  Memory 

1  MB  Floppy  Disk 

8  Serial  Communication  Ports 

1  27  MB  Winchester  Disk  Drive  and 

Controller 

2  Hard  Copy  Terminals 
2                    CRT  Terminals 

1  Uninterruptable  Power  Supply 
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TABLE  6.6   FUNCTIONAL /CARRIER  AIRWING  HARDWARE  ALLOCATION 


QUANTITY  DESCRIPTION 

1  PDF  11/23  CPU,  256  KB  Line  Clock 

1  MB  Floppy  Disk 

16  Serial  Coimnunication  Ports 

1  134  MB  Winchester  Disk  Drive  and 

Controller 

8  Optical  Link  Drivers 

4  Hard  Copy  Terminals 

4  CRT  Terminals 

1  Magnetic  Tape  Drive  and  Controller 

1  Uninterruptable  Power  Supply 

1  300  LPM  Printer  and  Controller 
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Input  data  to  PLS  include:  the  Naval  Aircraft  Flight 
Record  (OPNAV  3700/2),  X-Ray  (OPNAV  5442-1),  Engine  Trans- 
action Report,  Visual  Information  Display  System/Maintenance 
Action  Form,  Aircrew  Debrief  Forms  and  Personnel  Record  Forms. 
As  indicated  in  Figure  6.6,  these  inputs  will  automatically 
produce  historical  files  and  the  following  standard  outputs: 
Technical  Directive  Catalog,  Technical  Directive  Incorporation 
Status  Report,  Aircraft  Transaction  X-Ray  Message,  Engine  Trans- 
action Report  Message,  End  of  Operating  Quarter  Report,  Aircraft 
Accounting  Record,  Record  "A"  Report,  Daily  Flight  Time  Report, 
Personnel  Summaries  and  Aircrew  Training  Status. 

The  technical  directive  catalog  output  of  the  PLS  system 
is  produced  automatically  at  the  end  of  each  month  or  upon 
query.   This  report  summarizes  all  of  the  significant  data 
contained  in  the  technical  directive  source  document  (Visual 
Information  Display  System/Maintenance  Action  Form) .   Addition- 
ally, it  specifically  describes  the  status  and  effectivity 
of  each  technical  directive  issued  for  each  type  of  aircraft, 
engine  or  aeronautical  equipment.   The  Configured  Item  Status 
output  of  the  PLS  system  is  generated  daily,  upon  query,  or 
as  directed.   It  is  specifically  designed  to  provide  the  main- 
tenance manager  with  real  time  information  regarding  config- 
uration impacts  and  removal  schedules.   This  report  contains 
status  information  on  each  individual  serialized  component 
installed  in  assigned  aircraft  and  engines.   The  Technical 
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Directive  Incorporation  Status  output  is  produced  monthly  or 
upon  query.   It  provides  a  summary  of  the  status  of  incorpor- 
ated/not incorporated  technical  directives  in  each  assigned 
aircraft  or  engine.   This  output  can  be  utilized  to  verify 
the  TDSA  Lists  02  and  04  on  a  real  time  basis.   Although  addi- 
tional PLS  outputs  provide  significant  management  information, 
they  are  not  directly  related  to  configuration  status  account- 
ing and  are  therefore  not  discussed  in  this  thesis. 

One  advantage  to  organizational  level  management  is  that 
PLS  is  a  bottom-up  system.   It  was  designed  at  the  working 
level  which  is  in  sharp  contrast  to  most  other  systems,  inclu- 
ding NALCOMIS,  which  have  been  designed  from  the  top  down. 
It  is  the  authors'  opinion  that  top-down  systems  are  frequently 
designed  around  reporting  requirements  rather  than  around  or- 
ganizational level  management  information  needs.   PLS  provides 
both  real-time  configuration  management  information  and  summary 
data  formatted  to  meet  higher  level  information  and  report 
requirements . 

PLS  is  capable  of  maintaining  configuration  status  account- 
ing data  only  on  technical  directives  physically  incorporated 
and  documented  by  the  reporting  custodian  (squadron) .   Although 
PLS  provides  serial  number  component  control,  it  is  deficient 
as  a  result  of  its  inability  to  track  technical  directives 
incorporated  in  avionics,  engines  or  other  aeronautical  equip- 
ment by  intermediate  or  depot  activities. 
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The  fact  that  PLS  is  neither  a  NAVAIR-wide  system  nor  in- 
teractive with  the  NAVAIR  prescribed  systems  is  a  major  draw- 
back.  Specifically  in  the  area  of  configuration  status 
accounting,  PLS  does  nothing  more  than  duplicate  and  compile 
the  data  currently  available  in  the  Maintenance  Data  Collec- 
tion System.   Because  PLS  data  entry  requires  transcription 
of  the  manually  originated  maintenance  data  entry  form  (Visual 
Information  Display  System/Maintenance  Action  Form) ,  the  level 
of  system  accuracy  will  not  be  significantly  improved.   How- 
ever, the  information  will  be  more  current,  as  data  entry  is 
done  at  the  squadron  level,  rather  than  at  a  remotely  located 
data  processing  facility. 

F.   SUMMARY 

In  this  chapter  four  of  the  many  independently  developed 
configuration  status  accounting/maintenance  management  infor- 
mation systems  have  been  reviewed.   VAMP  was  specifically  de- 
veloped for  use  at  the  intermediate  level  of  maintenance  to 
manage  only  VAST  supported  avionics  components.   CMIS,  devel- 
oped by  Grumman  Aerospace,  applies  to  only  F-14  aircraft  spe- 
cific modifications  accomplished  at  either  the  organizational 
or  depot  levels  of  maintenance.   PLS,  a  CNAL  initiative,  is 
being  developed  to  provide  improved  maintenance  management/ 
configuration  status  accounting  information  at  the  organiza- 
tional and  functional/carrier  air  wing  levels.   With  regard 
to  configuration  documentation,  PLS  only  accounts  for  modifications 
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incorporated  at  the  organizational  and  depot  levels  of  main- 
tenance.  ECOMTRAK  is  being  implemented  to  provide  on-line 
information  necessary  to  manage  engine  configuration  and  main- 
tenance at  the  organizational,  intermediate  and  depot  levels. 

Of  these  four  systems,  only  VAMP  and  ECOMTRAK  are  designed 
to  be  compatible  with  NALCOMIS  and  NALDA.   CMIS  and  PLS,  al- 
though valuable  tools,  duplicate  TDSA  and  each  other.   All 
four  systems  reviewed  in  this  work  duplicate  the  data  entry 
requirements  of  the  TDSA  System.   With  the  exception  of  ECOMTRAK, 
none  of  the  systems  are  designed  to  support  serial  number 
tracking  of  components  as  they  migrate  through  the  three  levels 
of  maintenance.   Additionally  CMIS  and  PLS  do  not  track  the 
configuration  status  of  aircraft  installed  engines,  weapon 
relaceable  assemblies  and  ejection  seats. 

The  major  advantages  all  four  systems  have  over  the  TDSA 
and  NALDA  systems  are  improved  accuracy,  timeliness  and  acces- 
sibility of  maintenance  management  information  necessary  to 
support  the  aviation  maintenance  effort.   The  major  disadvan- 
tage of  local  systems  in  general  is  the  lack  of  NAVAIR  system 
standardization  and  integration.   Consequently,  logistic  sup- 
port based  on  the  information  provided  by  these  systems  is 
less  than  optimum. 
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VII.   NAVAL  AVIATION  LOGISTICS  COMMAND  MANAGEMENT 
INFORMATION  SYSTEM  (NALCOMIS) — THE  FUTURE 

A.   HISTORY 

The  proliferation,  redundancy  and  inconsistency  of  exist- 
ing management  information  systems  has  been  a  topic  of  concern 
in  the  Navy  for  several  years.   Rapidly  advancing  technology 
has  greatly  increased  the  complexity  of  Naval  aircraft  and 
the  number  of  actions  required  to  maintain  them.   As  a  result, 
the  volume  of  information  needed  to  forecast,  schedule,  moni- 
tor and  report  maintenance  actions  has  also  increased.   The 
Naval  Aviation  Maintenance  and  Material  Management  System  was 
devised  and  implemented  in  1965  to  collect  and  process  this 
information.   Constrained  by  the  automated  data  processing 
technology  of  the  time,  it  is  only  a  partially  automated  sys- 
tem.  Data  is  originated  manually  and  then  later  keypunched 
into  a  computer.   The  increased  volume  of  transactions  and 
the  transition  from  manual  collection  and  input  to  automated 
compilation  and  storage  has  introduced  problems  that  open  the 
system  to  skepticism  and  distrust  by  the  users. 

In  an  attempt  to  improve  carrier  aircraft  readiness,  the 
Chief  of  Naval  Operations  established  in  1970  the  Carrier  Air- 
craft Maintenance  Support  Improvement  (CAMSI)  Project.   With 
regard  to  shipboard  aircraft  maintenance  and  support  management, 
the  CAMSI  findings  indicated  that  an  acceptable  level  of  effi- 
ciency could  be  obtained  in  the  most  practical  and  cost  effective 
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manner  through  the  improved  use  of  automated  data  processing 
equipment  [Ref.  23]. 

In  response  to  the  CAMSI  findings,  NAVAIR  and  the  Naval 
Supply  Systems  Command  initiated  a  joint  project  in  1972  titled 
Shipboard  Aviation  Command  Management  Information  System  (SACOMIS) 
The  purpose  of  the  SACOMIS  project  was  to  design  and  develop 
an  automated  management  information  system,  and  the  SACOMIS 
Automated  Data  Systems  plan  concept  was  approved  by  the  Chief 
of  Naval  Operations  in  1974.   Also  in  that  year,  the  Chief 
of  Naval  Operations  directed  that  SACOMIS  additionally  include 
Naval  Air  Stations,  Marine  Corps  Air  Stations,  Marine  Aircraft 
Groups,  Helicopter  Aircraft  Carriers  and  Helicopter  Assault 
Aircraft  Carriers.   At  this  time  the  title  of  the  program  was 
changed  from  SACOMIS  to  NALCOMIS.   Thus,  what  started  as  a 
carrier  aircraft  specific  project  was  expanded  to  include  all 
of  Naval  and  Marine  Corps  aircraft.   It  is  intended  to  be  an 
effective,  real  time,  automated,  user-oriented  system  for  avia- 
tion maintenance  and  logistic  support  personnel.   Its  purpose 
is  "to  improve  operational  readiness  of  Navy  and  Marine  Corps 
aviation  units  through  improvements,  via  automation,  of  air- 
craft maintenance  and  supply  management  effectiveness."  [Ref. 
15] 

NALCOMIS  is  being  developed  using  a  modular  approach  with 
the  Module  I  Automated  Data  Systems  Plan  submitted  in  October 
1976.   This  module  was  certified  in  1977  and  applied  to  only 
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the  Organizational  Maintenance  Activity  (OMA) ,    Intermediate 
Maintenance  Activity  (IMA)  and  Supply  Support  Center  (SSC) 
areas  of  Naval  and  Marine  Corps  aviation.   The  following  dis- 
cussion of  NALCOMIS  deals  with  NALCOMIS  Module  I. 

B.   NALCOMIS  SYSTEM  DESIGN 

NALCOMIS  was  initially  designed  as  a  site-oriented  cen- 
tralized system  in  which  each  naval  air  station,  aircraft  car- 
rier, etc.  would  have  a  central  processor  and  a  single  integrated 
data  base.   However,  this  concept  proved  to  be  unsatisfactory 
for  supporting  the  requirements  of  Marine  Corps  and  Navy  users. 
Consequently,  it  was  changed  to  an  Independent /Distributive 
Data  Base  design.   It  is  currently  comprised  of  three  Indepen- 
dent Functional  Processes  (IFPs) ,  one  each  for  the  OMA  (IFP-A) , 
IMA  (IFP-B)  and  SSC  (IFP-C) .   The  accompanying  hardware  consists 
of  an  independent  Remote  Peripheral  Subsystem  Processor  located 
at  each  OMA  and  at  the  IMA.   The  remote  processor  of  each  unit 
holds  the  data  base  unique  to  that  unit.   A  central  processor 
holds  the  Common  Data  Base  (data  common  to  or  required  by  all 
users) .   There  is  also  a  networking  provision  that  allows  access 
for  authorized  users  to  data  in  the  distributed  data  bases 
and  the  Common  Data  Base.   Required  interfaces  to  provide  data 
to  external  systems  are  being  provided  for  all  three  IFPs. 
Interface  with  the  Naval  Aviation  Maintenance  and  Material 
Management  System  is  currently  planned. 
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The  change  to  the  Independent/Distributed  Data  Base  design 
offers  several  advantages  over  the  original  centralized  design 
with  regard  to  satisfying  the  needs  of  the  users.   It  allows 
the  system  to  be  implemented  on  a  squadron-by-squadron  basis 
without  interfering  with  deployment  schedules  and  other  require- 
ments.  With  each  unit  possessing  its  own  remote  processor 
and  storing  its  own  data  base,  the  response  time  from  the  sys- 
tem is  optimized.   The  distributed  remote  processors  allow 
units  to  deploy  and  still  retain  their  automated  organizational 
level  capability,  a  critical  requirement  for  Navy  and  Marine 
Corps  units.   Failure  of  one  component  of  the  system  does  not 
render  the  entire  system  unusable.   This  would  not  have  been 
possible  under  the  central  processor  concept. 

C.   NALCOMIS  PROVISIONS  FOR  CONFIGURATION  STATUS  ACCOUNTING 

In  general,  NALCOMIS  automates  the  manual  Visual  Informa- 
tion Display  System/Maintenance  Action  Form  which  is  currently 
used  for  recording,  controlling  and  monitoring  aircraft  main- 
tenance.  It  also  collects,  processes  and  stores  flight  acti- 
vity data  and  personnel  management  data.   In  addition,  IFP-B 
(IMA)  provides  repairables  management  capabilities  and  IFP-C 
(SSC)  includes  repairables  management  and  requisition  process- 
ing functions.   All  IFPs  include  a  Configuration  Status  Account- 
ing Subsystem.   To  date,  IFP-A  (OMA)  is  the  only  Independent 
Functional  Process  completed,  and  it  is  being  tested  at  one 
Naval  Air  Station  and  one  Marine  Corps  Air  Station.   Consequently 
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the  documentation  for  IFP-A  Configuration  Status  Accounting 

Subsystem  is  more  concise  and  detailed  than  that  for  either 

IFP-B  or  IFP-C. 

1.   IFP-A 

The  Configuration  Status  Accounting  Subsystem  of 

IFP-A  provides: 

...those  functions  required  to  establish  the  aircraft 
configuration  record  and  to  maintain  configuration  of 
the  engines  and  components  that  make  up  aircraft  or 
Support  Equipment  (SE)  and  will  include  capability  for 
serial  number  tracking  and  Technical  Directive  (TD) 
management.  [Ref.  24] 

Those  configuration  items  that  require  serial  number  tracking 

as  directed  by  higher  authority  can  be  accommodated  under  IFP-A, 

In  addition,  each  command  may  select  and  track  additional  items 

through  this  subsystem. 

The  three  main  divisions  of  this  subsystem  are  Engine 
Configuration,  Component  Configuration  and  Technical  Directive 
Management.   The  Engine  Configuration  section  tracks  specific 
engines  and/or  engine  module  serial  numbers  for  installed  and 
uninstalled  engines.   It  also  maintains  aeronautical  equipment 
service  record  information  for  engines  and  engine  modules. 

The  Component  Configuration  section  tracks  aircraft, 
support  equipment,  and  engine  components  by  serial  number. 
If  the  components  are  controlled  by  individual  cards  in  the 
engine  logbook,  they  are  specially  flagged,  since  additional 
information  is  required  in  the  NALCOMIS  record. 
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The  Technical  Directive  Management  section  tracks  in- 
formation relating  to  technical  directives  for  aircraft,  support 
equipment,  engines  or  components.   It  indicates  applicable 
technical  directives  for  specific  bureau  and/or  serial  numbers 
and  the  technical  directive  incorporation  status.   Upon  tech- 
nical directive  incorporation,  a  notice  is  printed  for  main- 
tenance control  to  make  the  required  logbook  entries. 

Data  for  this  subsystem  is  initially  established  through 
a  manual  configuration  update  menu.   Actual  aircraft  config- 
uration, current  technical  directive  applicability,  engine 
configuration,  engine  installation  status,  and  component  con- 
figuration are  initially  entered  through  this  option.   Addi- 
tionally, this  option  is  used  to  add  or  delete  records  or 
aircraft/engines/components  that  are  received  or  transferred. 

There  is  also  a  provision  for  an  automated  configuration 
update.   This  portion  of  the  subsystem  interacts  with  the  Main- 
tenance Activity  Subsystem  (automated  Visual  Information  Display 
System/Maintenance  Action  Form)  to  automatically  update  esta- 
blished configuration  records.   This  automated  update  occurs 
when  maintenance  actions  affecting  configuration  are  performed, 
such  as  technical  directive  incorporation  or  equipment  installa- 
tion and  removal.   The  automated  configuration  update  encompasses 
engines,  engine  components,  aircraft  and  support  equipment. 
In  addition,  the  technical  directive  update  section  provides 
a  notice  to  maintenance  control  if  the  incorporation  of  a  tech- 
nical directive  requires  a  part  number  change. 
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Also  included  in  the  Configuration  Status  Accounting 
Subsystem  of  IFP-A  is  a  configuration  interchangeability/ 
compatibility  section.   For  components  whose  configuration 
is  maintained  through  this  subsystem,  a  listing  of  those  com- 
ponents which  may  or  may  not  be  interchangeable  can  be  manually 
recorded  by  Federal  Supply  Code  or  Manufacturer /Part  Number. 

Configuration  information  may  be  retrieved  in  the  form 
of  inquiries  and  reports.   The  inquiries  available  are: 

1.  Engine  Serial  Number  Location 

2 .  Component  Configuration  Location 

3.  Technical  Directives 

4 .  Interchangeability/Compatibility 

The  first  two  options  provide  location  information  for  specific 
engine  or  component  serial  numbers,  i.e.  where  an  engine  or 
component  is  installed.   This  information  may  also  be  obtained 
for  all  engines  assigned  to  an  organization.   The  Technical 
Directive  inquiry  gives  technical  directive  information  for 
a  specific  technical  directive  code  and  a  specific  aircraft/ 
engine /component .   The  fourth  inquiry  lists  interchangeability/ 
compatibility  information  for  a  specific  Federal  Supply  Code 
or  Manufacturer /Part  Number. 

The  hard  copy  reports  available  are  as  follows: 
1.   Aircraft  Configuration  (including  engines  and  components) 
for  a  specific  type/model/series  or  bureau  number  or  for  all 
aircraft  within  a  squadron 
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2.  Engine  Configuration  (including 'modules  and  components) 
for  a  specific  type/model/series  or  serial  number  or  for  all 
engines  held  by  a  squadron 

3.  Technical  Directive  Configuration  for  a  given  technical 
directive  code  and  number.   This  report  lists  the  technical 
directive's  applicability  to  squadron  held  items  and  whether 

or  not  the  technical  directive  has  been  incorporated  in  those 
items 

4.  Component  Location  of  a  specific  Federal  Supply  Code 
or  Manufacturer/Part  Number  for  the  bureau  number  plus  any 
interchangeable  parts  listed  for  that  number 

The  IFP-A  Configuration  Status  Accounting  Subsystem 
concept  established  a  preferred  configuration  for  each  air- 
craft, engine  and  component.   The  actual  configuration  for 
a  particular  aircraft,  engine  and/or  component  can  then  be 
compared  to  its  preferred  configuration  and  discrepancies  re- 
ported.  The  preferred  or  optimum  configuration  profiles  are 
created,  revised,  or  deleted  in  the  Manual  Configuration  Update 
portion  of  the  subsystem. 
2.   IFP-B  and  IFP-C 

As  stated  above,  the  IFP-B  and  IFP-C  portions  of  NALCOMIS 
are  not  complete,  and  the  documentation  concerning  the  Config- 
uration Status  Accounting  capabilities  is  not  yet  detailed. 
In  general,  the  IFP-B  is  intended  to  have  the  IFP-A  capabilities 
for  engines,  components  and  support  equipment  as  well  as  the 
ability  to  track  technical  directives.   The  IFP-C  is  intended 
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to  have  only  the  inquiry  and  report  generating  capability  for 
Configuration  Status  Accounting  and  only  when  the  IFP-A  and 
IFP-B  functions  are  available. 

D.   CONFIGURATION  STATUS  ACCOUNTING  IMPROVEMENTS 

NALCOMIS  offers  many  improvements  to  the  current  config- 
uration status  accounting  system.   It  gives  the  organizational 
and  intermediate  maintenance  levels  a  real-time  interactive 
management  information  system  for  monitoring  actual  aircraft/ 
engine /support  equipment  configuration  and  technical  directive 
incorporation  status.   When  provided  with  upline  reporting 
capability  through  the  Naval  Aviation  Maintenance  and  Material 
Management  System  interface,  NALCOMIS  in  conjunction  with  NALDA 
corrects  many  of  the  problems  that  invite  criticism  of  the 
current  system. 

Data  accuracy  within  NALCOMIS  is  improved  for  several 
reasons . 

1.  Visual  Information  Display/Maintenance  Action  Forms 
are  no  longer  hand  written,  and  their  transcription  via  key 
punch  is  no  longer  required. 

2.  The  data  within  each  remote  processor  is  self  verified 
and  updated.   Therefore,  incompatible  maintenance  action  in- 
formation can  not  be  entered.   Once  current  data  is  entered 

in  one  area  it  is  updated  throughout  the  data  base. 

3.  Fewer  individuals  originate  the  information  and  enter 
it  into  the  system. 
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4.  Reconciliation  of  hand  written  data  with  machine  gen- 
erated reports  is  not  required. 

5.  Transactions  with  missing  data  (such  as  technical  di- 
rective incorporation  manhours)  are  not  accepted. 

6.  Misplaced  and  lost  configuration  lists  are  not  a  pro- 
blem, as  new  lists  can  be  generated  as  needed. 

It  is  anticipated  that  there  will  be  improved  standardiza- 
tion of  all  configuration  information,  especially  across  func- 
tional wings,  type  commands  and  carrier  air  wings.   The  depth 
and  organization  of  configuration  data  is  consistent,  allowing 
mid-level  and  upper-level  managers  to  make  comparisons  and 
compilations.   Serial  number  tracking  of  components,  which 
is  presently  done  manually  through  a  varying  number  of  local 
systems  (if  it  is  done  at  all) ,  is  performed  in  a  structured 
and  manageable  form. 

Management  of  technical  directive  change  kits  is  greatly 
improved.   Kit  managers  have  access  to  more  up-to-date,  com- 
plete information  concerning  kit  requirements,  issue  and  in- 
corporation.  This  in  turn  gives  them  more  control  over  kit 
procurement,  redistribution,  cannibalization  and  disposal. 

Significant  improvements  can  be  expected  in  aircraft/ 
engine /support  equipment  performance  and  safety  as  the  system 
develops.   An  improved  management  information  system  results 
in  more  accurate  weight  and  balance  data.   The  movement  of 
components  from  one  aircraft  or  engine  to  another  can  be  more 
accurately  tracked.   With  up-to-date,  accurate  information 

110 


there  is  less  chance  of  installing  incompatible  components. 
Technical  directive  change  requirements  are  more  readily  iden- 
tifiable, allowing  units  to  take  advantage  of  the  safety  and 
performance  improvements  which  were  the  bases  for  the  changes. 
As  a  result,  technical  directive  incorporation  brings  about 
improved  design,  stability,  control  and  mission  capability. 

Implementation  of  NALCOMIS  is  expected  to  improve  the  lo- 
gistic supportability  of  the  aircraft  and  supporting  equipment. 
If  the  configuration  of  these  items  can  be  accurately  ascer- 
tained, spare  parts  and  material  support  can  be  better  planned 
and  implemented.   This  in  turn  allows  the • proper  provisioning 
in  both  the  range  and  depth  of  spare  parts  required  and  iden- 
tifies those  parts  that  may  be  purged  to  open  up  needed  storage 
space  and  reduce  inventory  holding  costs.   In  addition,  main- 
tenance technician  training  can  be  correctly  scheduled  based 
on  the  actual  equipment  to  be  supported.   Improved  provisioning 

and  training  contributes  to  the  improved  safety  and  performance 
discussed  above. 

E.   CONFIGURATION  STATUS  ACCOUNTING  DEFICIENCIES 

Even  with  the  improvements  NALCOMIS  brings  to  configuration 
status  accounting,  some  problem  areas  will  remain.   For  example, 
logbook  entries  will  still  be  accomplished  manually  with  the 
resulting  possibilities  for  errors.   Consequently,  the  require- 
ment for  verification  between  the  logbook  entries  and  the  con- 
figuration information  held  by  NALCOMIS  will  still  exist.   A 


111 


provision  for  an  automatically  printed  logbook  page  would 
greatly  enhance  the  system. 

There  is  not  at  present  an  Independent  Functional  Process 
planned  for  use  at  the  functional  wing,  type  commander  or  car- 
rier airwing  staff  levels.   As  the  distributed  system  is  cur- 
rently designed,  configuration  information  across  an  airwing 
would  be  obtained  from  each  squadron  remote  processor  and  man- 
ually aggregated.   A  staff  level  process  for  extracting  and 
sorting  this  information  is  required  to  convey  the  data  to 
upper  management  levels.   In  addition,  staffs  require  a  long 
range  configuration  planning  capability,  such  as  that  currently 
used  in  conjunction  with  the  Grumman  Configuration  Management 
Information  System.   NALCOMIS  contains  information  about  air- 
craft that  is  essential  for  planning  overhaul  and  deployment 
assignments.   Such  information  should  be  made  available  to 
those  managers  who  are  making  these  decisions. 

The  distributed  system  allows  an  air  station  or  carrier 
to  continue  operation  in  the  event  of  a  remote  processor  fail- 
ure.  However,  backup  capability  for  a  squadron  should  its 
remote  processor  fail  must  be  addressed.   It  is  unacceptable 
for  maintenance  operations  to  be  halted  for  even  short  periods 
due  to  the  inaccessibility  of  the  information  held  by  NALCOMIS, 
and  manual  backup  would  systems  only  defeat  the  purpose  of 
NALCOMIS.   Redundant  hardware  and  spare  components  should  be 
provided  within  NALCOMIS  (especially  in  remote  location)  to 
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allow  units  to  continue  operation  while  inoperative  hardware 
is  being  repaired. 

At  the  present  time,  NALDA  provides  information  on  only 
airframe  and  engine  technical  directive  changes.   This  capa- 
bility must  be  expanded  to  include  other  changes  such  as 
avionics,  aircrew  and  support  equipment. 

Finally,  the  implementation  of  NALCOMIS  must  be  carefully 
planned.   If  the  current  configuration  data  base  is  used  in 
its  present  form,  the  system  will  be  inaccurate  from  the  start 
Significant   time  and  effort  will  be  required  to  ensure  that 
technical  directive  status  accounting  records  are  accurate 
and  up  to  date  with  regard  to  the  actual  configuration  of  the 
aircraft. 
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VIII.   CONCLUSIONS  AND  RECOMMENDATIONS 

A.  CONCLUSIONS 

Based  on  configuration  status  accounting  research  conducted 
for  this  thesis,  the  following  conclusions  are  made: 

1.  The  existing  TDSA  and  NALDA  systems  lack  the  means 
to  identify,  collect,  sort,  collate  and  communicate  config- 
uration status  accounting  data  in  a  timely  and  accurate  manner. 

2.  Local  systems  developed  as  a  result  of  budgetary  lim- 
itations and  TDSA/NALDA  system  deficiencies  provide  significant- 
ly improved  configuration  status  accounting  information  but 
only  for  their  specific  application. 

3.  The  proliferation  of  locally  developed  systems  lack 
overall  coordination,  integration  and  standardization.   On 
the  whole  this  decreases  NAVAIR  logistic  support  and  mainte- 
nance management  effectiveness. 

4.  NALCOMIS,  with  modification,  has  the  potential  to  satis- 
fy NAVAIR  configuration  status  accounting  management  information 
needs. 

B.  RECOMMENDATIONS 

Based  on  the  above  conclusions,  the  following  recommendations 
are  made : 

1.   Expedite,  to  the  maximum  extent  possible,  development 
and  full  implementation  of  NALCOMIS.   Additionally,  include 
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within  NALCOMIS  provisions  for  upline  reporting  to  functional 
wings,  carrier  air  wings  and  type  commanders. 

2.  Develop  as  a  basic  aviation  maintenance  data  collec- 
tion goal,  one-time  entry  of  each  data  element  for  use  by  all 
aircraft  maintenance  management  information  systems, 

3.  Expand  NALDA  to  include  all  technical  directive  change 
categories  and  comprehensive  component  serial  number  tracking. 
Provide  additional  NALDA  terminals  at  all  user  sites.   As  an 
interim  measure,  improve  TDSA  timeliness  by  increasing  the 
distribution  frequency  of  Lists  02  and  04. 

4.  Authorize  the  continued  operation  of  all  existing  local 
systems,  restricting  investment  in  system  improvement,  until 
NALCOMIS  has  been  implemented  fully. 

5.  Develop  a  NAVAIR  committee  to  review  and  approve  emer- 
gent and  existing  management  information  systems  to  ensure 
integration  with  NALCOMIS. 

6.  Initiate  action  to  improve  the  accuracy  of  the  TDSA/ 
NALDA  data  base  by  a)  reducing  errors  during  Visual  Information 
Display/Maintenance  Action  Form  transcription  and  b)  enforcing 
depot  level  technical  directive  verifications  conducted  during 
rework. 

7.  Increase  the  utilization  of  ECOMTRAK  and  VAMP  to  cover 
all  intermediate  and  depot  avionics  and  engine  types. 
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APPENDIX  A 
ACRONYMS  LIST 


AIMSO 

CAMS  I 

CI 

CMC 

CMIS 

CNAL 

CNAP 

DOD 

ECOMTRAK 

I 

IFP 

ILS 

IMA 

MAG 

NALC 

NALCOMIS 

NALDA 

NAVAIP. 

NAVMAT 

NAVMATINST 

NAVSUP 

0 


Aircraft  Intermediate  Maintenance  Support  Office 

Carrier  Aircraft  Maintenance  Support  Improvement 

Configuration  Item 

Commandant  of  the  Marine  Corps 

Configuration  Management  Information  System 

Commander,  Naval  Air  Force,  U.S.  Atlantic  Fleet 

Commander,  Naval  Air  Force,  U.S.  Pacific  Fleet 

Department  of  Defense 

Engine  Composition  Tracking 

Intermediate  Maintenance  Level 

Independent  Functional  Process 

Integrated  Logistics  Support 

Intermediate  Maintenance  Activity 

Marine  Air  Group 

Naval  Aviation  Logistics  Command 

Naval  Aviation  Logistics  Command  Management 

Information  System 

Naval  Aviation  Logistic  Data  Analysis 

Naval  Air  Systems  Command 

Naval  Material  Command 

Naval  Material  Command  Instruction 

Naval  Supply  Systems  Command 

Organizational  Maintenance  Level 
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OMA 
OPNAV 
PLS 
SACOMIS 

SRA 

SSC 

TDSA 

TYCOM 

VAMP 

VAST 

WRA 


Organized  Maintenance  Activity 

Chief  of  Naval  Operations 

Portable  Logistics  Support 

Shipboard  Aviation  Command  Management 

Information  System 

Shop  Replaceable  Assembly 

Supply  Support  Center 

Technical  Directive  Status  Accounting 

Type  Commander 

VAST  Automated  Management  Program 

Versatile  Avionics  Shop  Test 

Weapon  Replaceable  Assembly 
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APPENDIX  B 
GLOSSARY 


1.  AVIATION  MAINTENANCE  AND  MATERIAL  MANAGEMENT  SYSTEM  (3-M) : 
A  subsystem  of  the  Naval  Aviation  Maintenance  Program 
designed  for  the  purpose  of  providing  maintenance  data 
collection,  manhour  accounting  and  aircraft  accounting. 

2.  ALLOCATED  BASELINE;  The  formally  designated  allocated 
configuration  identification  fixed  as  a  product  of  the 
demonstration  and  validation  phase  of  the  life  cycle. 

3.  AUDIT:   To  inspect  records  and  procedures. 

4.  BASELINE;   An  approved  reference  point  for  control  of 
future  changes  to  a  product's  performance,  construction 
and  design. 

5.  CARRIER  AIR  WING;  The  staff  directly  responsible  for 
providing  operational,  maintenance  and  administrative 
support  to  all  assigned  squadrons  located  onboard  the 
same  aircraft  carrier. 

6.  CHANGE;   Within  the  context  of  configuration  control, 

a  formally  recognized  revision  to  a  specified  and  docu- 
mented Navy  material  requirement.   Includes  design 
changes,  engineering  changes,  field  changes,  technical 
directive  changes,  changes  in  specifications  or  other 
related  requirements. 

7.  CHANGE  IDENTIFICATION  NUMBER;   A  number  assigned  to  a 
data  package  defining  an  equipment  engineering  change. 
It  is  used  to  control,  sequence  and  account  for  pro- 
duction, implementation,  and  retrofit  actions  relating 
to  the  change . 

8.  COMPONENT;   A  part,  subassembly,  assembly  or  combination 
of  these  items  joined  together  to  perform  a  function. 

9.  CONFIGURATION;   The  functional  and/or  physical  charac- 
teristics of  hardware /software  as  set  forth  in  technical 
documentation  and  achieved  in  a  product. 

10.  CONFIGURATION  ITEM  (CI);   An  aggregation  of  hardware/ 
software,  or  any  of  its  discrete  portions,  which  satis- 
fies an  end  use  function  and  is  designated  by  the  Govern- 
ment for  configuration  management.   CIs  may  vary  widely 

in  complexity,  size,  and  type,  from  an  aircraft,  electronic 
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or  ship  system  to  a  test  meter  or  round  of  ammunition. 
During  development  and  initial  production,  CIs  are  only 
those  specification  items  that  are  referenced  directly 
in  a  contract  (or  an  equivalent  in-house  agreement) . 
During  the  operation  and  maintenance  period,  any  repair- 
able item  designated  for  separate  procurement  is  a  con- 
figuration item. 

11.  CONFIGURATION  MANAGEMENT:   A  discipline  applying  tech- 
nical and  administrative  direction  and  surveillance  to 

(1)  identify  and  document  the  functional  and  physical 
characteristics  of  a  configuration  item,  (2)  control 
changes  to  those  characteristics,  and  (3)  record  and 
report  change  processing  and  the  implementation  status 
of  approved  changes. 

12.  CONFIGURATION  STATUS  ACCOUNTING  (CSA) ;   The  recording 
and  reporting  of  an  approved  configuration  identifica- 
tion, and  the  status  of  proposed  changes  to  the  approved 
configuration  and  implementation  status  of  approved 
changes . 

13.  CONFIGURATION  CHANGE:  A  general  term  which  signifies 
that  the  configuration  of  an  item  has  been  or  will  be 
changed  through  the  configuration  control  process. 

14.  DEPOT  LEVEL:   The  top  level  of  the  three  levels  of 
maintenance.   Generally  considered  industrial  in  nature. 

15.  ENGINEERING  CHANGE  PROPOSAL:   A  document  that  proposes 
change  to  a  Navy  material  item  in  accordance  with  appli- 
cable bulletins,  regulations,  standards  and  other  directives 

16.  EQUIPMENT:   An  item  designed  and  built  to  perform  a  spe- 
cific function  as  a  self-contained  unit  or  to  perform  a 
function  in  conjunction  with  other  units.   It  is  the  same 
as  a  product. 

17.  FUNCTIONAL  BASELINE:   The  functional  configuration  iden- 
tification initially  approved  by  the  customer. 

18.  FUNCTIONAL  WING:   The  staff  directly  responsible  for  pro- 
viding operational,  maintenance,  and  administrative  support 
to  similar  aircraft  squadrons  located  in  the  same  geographic 
area. 

19.  INTERFACE:   A  region  common  to  two  or  more  elements,  sys- 
tems, projects  or  programs,  characterized  by  mutual  phy- 
sical, functional,  and/or  procedural  properties. 
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20.  INTEGRATED  LOGISTIC  SUPPORT  (ILS) ;  A  composite  of  the 
elements  necessary  to  assure  the  effective  and  econom- 
ical support  of  a  system  or  equipment  at  all  levels  of 
maintenance  for  its  programmed  life  cycle.  The  elements 
include  all  resources  necessary  to  maintain  and  operate 
an  equipment  or  weapons  system,  and  are  categorized  as 
follows:  (1)  planned  maintenance,  (2)  logistic  support 
personnel,  (3)  technical  logistic  data  and  information, 

(4)  support  equipment,  (5)  spares  and  repair  parts,  (6) 
facilities,  and  (7)  contract  maintenance. 

21.  INTERMEDIATE  LEVEL;  The  middle  level  of  the  three  levels 
of  maintenance. 

22.  KIT;  A  collection  of  carefully  identified  and  controlled 
items  used  to  build  a  module,  printed  circuit  board,  sub- 
assembly or  assembly. 

23.  LIFE  CYCLE:  The  period  covering  the  design,  development, 
manufacture,  operation,  maintenance,  logistic  support  and 
repair  of  an  equipment. 

24.  MODIFICATION:   A  change  to  an  equipment  and  spares  allowed 
only  after  the  contract  has  been  revised. 

25.  NAVAL  AVIATION  MAINTENANCE  PROGRAM  (NAMP) :   The  system 
prescribed  by  Chief  of  Naval  Operations  Instruction  4790. 2B 
to  manage  overall  aviation  maintenance  within  the  Navy. 

26.  ORGANIZATION  LEVEL:   The  lowest  of  the  three  levels  of 
maintenance.   In  aviation  it  is  the  squadron  level. 

27.  PRODUCT  BASELINE:   The  product  configuration  identification 
initially  approved  by  the  customer. 

28.  SHOP  REPLACEABLE  ASSEMBLY  (SRA) :   A  subcomponent  of  a  wea- 
pon replaceable  assembly  removed  as  a  result  of  an  inter- 
mediate level  maintenance  action. 

29.  SUBASSEMBLY:   Two  or  more  parts  that  form  a  portion  of  an 
assembly  replaceable  as  a  whole  but  having  a  part  or  parts 
that  are  individually  replaceable. 

30.  SUBSYSTEM;   A  major  functional  subsystem  or  group  of  items 
that  is  essential  to  operation  completeness  of  a  system. 

31.  SYSTEM;   A  composite  of  subsystems,  assemblies,  skills, 
and  techniques  capable  of  performing  and/or  supporting 
an  operational  (or  non  operational)  role.   A  complete 
system  includes  related  facilities,  items,  material, 
services  and  personnel  required  for  its  operation. 
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32.  TECHNICAL  DIRECTIVE;   An  official  document  describing 
technical  information,  instructions  and  safety  procedures 
related  to  operation,  maintenance,  installing  or  modifi- 
cation of  an  equipment. 

33.  TECHNICAL  DIRECTIVE  INDEX:   A  record  of  all  technical 
directives  by  weapon  system,  weapon,  system,  or  commodity 
from  the  date  the  technical  directive  number  is  assigned 
until  the  technical  directive  is  rescinded  or  cancelled. 

34.  TECHNICAL  DIRECTIVE  COMPLIANCE  STATUS  REPORTS:   A  series 
of  reports  that  record  the  compliance  status  of  all  formal 
and  interim  changes  in  the  NAVAIR  system,  including  kits, 
material,  and  manhour  information. 

35.  TYPE/MODEL/SERIES  (T/M/S) :   Refers  to  the  type,  model  and 
series  of  aircraft  in  the  NAVAIR  inventory  (i.e.,  A-4J — 
A  is  type  Attack,  4  is  the  model  and  J  is  the  series). 

36.  VALIDATION:   As  used  herein,  validation  comprises  those 
evaluation,  integration  and  test  activities  carried  out 
at  the  system  level  to  assure  that  the  finally  developed 
systems  satisfy  the  mission  requirements  of  the  system 
specifications . 

37.  VISUAL  INFORMATION  DISPLAY  SYSTEM/MAINTENANCE  ACTION  FORM 

(VIDS/MAF) ;   The  single  form  used  to  document  all  main- 
tenance actions  in  support  of  the  aviation  Maintenance 
and  Material  Management  System. 

38.  WEAPON  REPLACEABLE  ASSEMBLY  (WRA) :  A  component  removed 
from  an  aircraft  by  an  organizational  level  maintenance 
action. 
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